RFR: JDK-8202776: Modularize GC allocations in runtime

[Erik Österlund]

Hi Roman,

I agree the GC should be able to perform arbitrary allocations the way 
it wants to.
However, I would prefer to do it this way:
http://cr.openjdk.java.net/~eosterlund/8202776/webrev.00/

Your approach baked more responsibility into mem_allocate, having each 
GC remember it needs to call into allocate_from_tlab, which no longer 
always allocates from TLAB (depending on UseTLAB).

In my approach, a new virtual member function, obj_allocate_raw() is 
called, which by default conditionally calls allocate_from_tlab() if 
UseTLAB is on, and otherwise calls mem_allocate, exactly the way it is 
today. Yet it allows the flexibility of overriding obj_allocate_raw() to 
allocate the object in any crazy way imaginable.

What do you think about this approach? Does it work for you with Shenandoah?

Thanks,
/Erik

On 2018-05-14 13:40, Roman Kennke wrote:
> 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
>