RFR: JDK-8202776: Modularize GC allocations in runtime

[Erik Österlund]

Hi Roman,

I don't mind. I think this one is your patch, so I think I am still 
reviewing you. And I think it looks really good! :p

/Erik

On 2018-06-04 17:20, Roman Kennke wrote:
> 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
>>>
>