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