RFR: JDK-8202776: Modularize GC allocations in runtime
Erik Österlund
erik.osterlund at oracle.com
Mon Jun 4 21:24:08 UTC 2018
Hi,
Looks good.
Thanks,
/Erik
On 2018-06-04 23:20, Roman Kennke wrote:
> Hi Aleksey, Erik,
>
> thanks for reviewing and helping with this!
>
> Moved mem_allocate() under protected:
> Incremental:
> http://cr.openjdk.java.net/~rkennke/JDK-8202776/webrev.01.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/JDK-8202776/webrev.01/
>
> Good now?
>
> Thanks,
> Roman
>
>
>> Hi Aleksey,
>>
>> Sounds like a good idea.
>>
>> /Erik
>>
>>> On 4 Jun 2018, at 17:56, Aleksey Shipilev <shade at redhat.com> wrote:
>>>
>>> On 06/04/2018 05:29 PM, Erik Österlund wrote:
>>>>>> 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/
>>> This looks good. I think we better hide mem_allocate under "protected" now, so we would have:
>>>
>>> protected:
>>> // TLAB path
>>> inline static HeapWord* allocate_from_tlab(Klass* klass, size_t size, TRAPS);
>>> static HeapWord* allocate_from_tlab_slow(Klass* klass, size_t size, TRAPS);
>>>
>>> // Out-of-TLAB path
>>> virtual HeapWord* mem_allocate(size_t size,
>>> bool* gc_overhead_limit_was_exceeded) = 0;
>>>
>>> public:
>>> // Entry point
>>> virtual HeapWord* obj_allocate_raw(Klass* klass, size_t size,
>>> bool* gc_overhead_limit_was_exceeded, TRAPS);
>>>
>>> -Aleksey
>>>
>
More information about the hotspot-dev
mailing list