48 Transfer between PSpaces

Consider a huge sub-tree of persistent objects that should be transferred to another PSpace. This should be achieved quickly with a transaction that exclusive locks source and destination PSpaces.

However things are complicated by the following

  • The source CSpace may record objects to be moved in dE, E, D, R
  • The source PSpace may record objects to be moved in the DOS, ROT, PSpaceRoots.

If all objects in the source PSpace are to be transferred then we have a simpler solution, because we can readily shut down the source GC and DOS writer and perform the transfer without regard for the continued operation of the source space.

Otherwise it is not clear whether we should try to transfer the objects in memory. Consider that we don't. Now some of these objects in memory may be dirty (and recorded in the DOS of the source PSpace). We must not drop the existing changes to the object. Given that we don't intend to transfer the object in memory to the destination space, we must write the dirty object to disk.

We conclude that the transfer first requires processing of the DOS on the source PSpace. Now this requires shared read locks on a group of PSpaces. Unfortunately we have already exclusive locked the source and destination PSpaces! Therefore getting the shared read locks may not be feasible, because CSpaces must be locked in a total order.

Proposal

When the txn to perform the transfer is started, the exclusive lock on the source and dest PSpaces means that both become part of some group of PSpaces that can only be processed together with a single Lss transaction. Therefore we have an opportunity to synchronously make the transfer happen without any risk of partial changes being written to disk.

Consider that we block until the GC thread reaches an inactive point. Note that it can't have either a shared read or exlcusive lock. However it could easily be blocking while trying to get these locks. It could also be in the middle of deleting objects it has already chosen to evict. Note however that OnGarbageCollect() must have already been called on the objects to evict. Therefore these objects won't be in the ROT or DOS. In fact they are truely unreachable and therefore need to be deleted anyway.

Consider an object x that is dirty and in the DOS. It must be resident in memory and be recorded in the ROT. It also must be recorded in dE or E. It also may possible be a GC root. It may be a PSpace root.

Suppose that x needs to be transferred to another PSpace. We can't write x to the LSS so therefore we must transfer the object in memory. Hmmmm. This all sounds too difficult!

Conclusions

  • Partial, synchronous transfer of objects between PSpaces is too hard!
  • Complete transfer of a PSpace into another is easier to achieve. However it requires a sledgehammer effect to bring down the source CSpace. For example threads have to be stopped. Therefore this operation is comparatively expensive. To avoid holding an exclusive lock for too long it seems best to first (without a lock) bering down a CSpace/PSpace. This stops the GC thread.