RFR: JDK-8202776: Modularize GC allocations in runtime

Roman Kennke rkennke at redhat.com
Mon May 14 11:40:39 UTC 2018


Currently, GCs only get to see (and modify) 'large' allocations, e.g.
allocations of TLAB blocks (via CH::allocate_new_tlab()) or non-TLAB
objects (via CH::mem_allocate()). I think GCs need to own the whole
allocation path, including allocations *from* TLABs. For example,
Shenandoah needs to allocate one extra word per object, and do some
per-object initialization to set up the forwarding pointer.

More generally speaking, I believe the interface between GC and rest of
the world should just be 'allocate me a chunk of X words' and it should
be totally to the GCs decretion how and where it allocates that, how
objects are laid out and whatever pre- or post-processing needs to be done.

For runtime we're already mostly there in the form of
CollectedHeap::mem_allocate(). However, currently, TLAB allocation is
done outside of this path, and GCs cannot currently control it. This
patch propose to move the TLAB allocation to inside of mem_allocate().
On a more-or-less related not, it also makes
CollectedHeap::fill_with_object_impl() virtual, so that GCs can
intercept that too. (For example, Shenandoah needs to write a fwd ptr,
and then fill with one word less.)

http://cr.openjdk.java.net/~rkennke/JDK-8202776/webrev.00/

Passes: hotspot/tier1 tests

Can I please get a review?

Thanks, Roman



More information about the hotspot-dev mailing list