Breadth-first vs. Depth-first
martinrb at google.com
Sun Jun 8 22:12:52 UTC 2008
JavaOne 2008 technical session PDFs are now available
I enjoyed the discussion of breadh-first vs. depth-first GC copying
in the JavaOne talk
I'd like to suggest that this is a fruitful avenue for investigation,
if hotspot engineers go further than simply switching whole-hog
Profiling can find reference fields that are rarely dereferenced,
and also ones that are likely to be dereferenced soon after the object
itself is accessed.
The former can be sequestered by the next copying GC into
an unloved-object ghetto, while the latter can be stored contiguously
with its parent object. Tricky to implement, and will certainly
make GC slower, but might make the runtime of the mutator win big.
And should be easier to implement than true object inlining.
This ought to be very similar to the moving of dead or cold code
fragments inside a method away from the hot code, that hotspot
More information about the hotspot-gc-dev