RFR: JDK-8202776: Modularize GC allocations in runtime

[Roman Kennke]

Yes, your approach is even better. So are you reviewing me now, or
should I review you? :-P

Roman


> 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
>>
>