During a full gc, all live objects in the young gen are copied to the old gen as long as there is enough space.  When the heap is very full, all the young gen objects may not fit.  With par compaction, this often results in a long series of time-consuming full gcs which do not free up space in eden.  When par compact is copying from a young gen space (e.g., eden or from) to the old gen, *all* live objects in the space must fit into the old gen; otherwise, none of them will be copied.  This is because par compaction operates on fixed-size 'regions' of the heap and copying only part of a space would require extra bookkeeping (or some  customer  luck).

The extra bookkeeping should be implemented to allow a young gen space to be "split" so that as much as will fit is copied to the old gen and the rest is compacted down within the young gen space itself.
Posted Date : 2008-11-13 07:35:15.0

N/A

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.
Posted Date : 2008-11-10 19:10:36.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7c2386d67889
Posted Date : 2008-12-12 03:18:45.0