RFR: 8205683: Refactor heap allocation to separate concerns

Per Liden per.liden at oracle.com
Wed Jun 27 14:26:59 UTC 2018


Hi Erik,

On 2018-06-27 15:23, Erik Österlund wrote:
> Hi Per,
> 
> Thank you for reviewing.
> 
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8205683/webrev.02_03/
> 
> Full:
> http://cr.openjdk.java.net/~eosterlund/8205683/webrev.03/
>[...]
>> I doesn't look like the above functions need to take in TRAPS, right?
> 
> It is used by callers so they can use the CHECK_NULL macro on the 
> callsite. But inside, I don't need it.

Ah, I see. I tend to think that we're only using that style when 
something inside throws and exception, but anyway, keep it as is.

[...]
>> src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
>> ------------------------------------------------------
>>
>> 143   HeapWord* allocate_sampled_object(size_t size);
>>
>> Can we call this function allocate_sampled() to better match with 
>> allocate()?
> 
> Not sure where you found this function; I have removed it. The logic was 

You're right of course, ignore me.

> instead moved into the allocate_inside_tlab_slow function. One 
> alternative I considered is to pass in a bool* to 
> ThreadLocalAllocBuffer::allocate() that if not NULL also tries to bump 
> the end to its actual end, and returns back whether the end was bumped 
> by the sampling logic or not inside of allocate, and have that pointer 
> point straight into Allocation::_tlab_end_reset_for_sample. If you 
> prefer that style, I can change it to do that instead.

I like what you have now, so I'd say keep it as is.

In summary, looks good, ship it!

cheers,
Per

> 
> Thanks,
> /Erik
> 
>>
>> cheers,
>> Per
> 



More information about the hotspot-gc-dev mailing list