EVALUATION
Since par compact operates on fixed-size regions of the heap, a space can only be split at a region boundary to avoid dramatically slowing down the calculation of the new location of a pointer (a very hot code path). Since objects cannot be split, a split must be done at a region boundary that is not spanned by a live object. When a split is necessary (very full heap), such boundaries are scarce.
Par compact already keeps track of partial objects--which are the tail ends of objects which span region boundaries. Given this and a little extra bookkeeping, a region can be split just after the end of a partial object without affecting hot code paths.
When splitting a region, the partial object and everything to its left will be copied to another space (call it destination space 1, or d1). The live data to the right of the partial object will be copied either within the space itself, or to another destination space (d2, which is distinct from d1). Since the partial object will have no effect on the locations of other objects destined for d2, the data about the partial object can be saved in a side data structure and removed from the main summary table (summary_data).
More specifically, when the par compact summary phase determines that a region needs to be split, it records the following in a separate "SplitInfo" table:
the region being split
the size of the partial object crossing onto the region
the destination address of the first word of the partial object
the destination count of the partial object (the number of regions it will be copied to--1 or 2)
the destination region boundary (if it will be copied to 2 regions)
the address of the first word within the partial object to be copied to the second destination region
(again if it will be copied to 2 regions)
A space is split at most once, so the amount of data is small and fixed size. The info is needed only when finding the first word to be copied to a destination region, which is done once per region and so has no noticeable effect on performance. The tricky part is recording the data properly during the summary phase.
|
Java