RFR: JDK-8211955: GC abstraction for LAB reserve

Roman Kennke rkennke at redhat.com
Thu Oct 11 09:24:50 UTC 2018


Hi Per,

> Hi,
> 
> On 10/10/2018 11:08 PM, Roman Kennke wrote:
>> Hi Aleksey,
>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.01.diff/
>>>> Full:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.01/
>>>
>>> I think you were right with "dummy" name symmetry, but I have not
>>> strong opinion either.
>>
>> Haha, ok. Let's change it back, but without words, ok?
>>
>>> In plab.cpp, this header is not needed anymore?
>>>    30 #include "oops/arrayOop.hpp"
>>
>> Right. Fixed.
>>
>>> ...and maybe not even this one?
>>>    31 #include "oops/oop.inline.hpp"
>>
>> Still needed elsewhere I think.
>>
>>>> Let's wait for the Epsilon test fix...
>>>
>>> FWIW, the running with candidate fix for JDK-8212005 applied passes
>>> x86_32 tier1_gc.
>>
>> Ok, cool. Here's the updated webrevs:
>> Incremental:
>> http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.02.diff/
>> Full:
>> http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.02/
>>
>> Good now?
> 
> I'm not sure I understand why we need yet another abstraction for this.
> I'm thinking the stuff you did in JDK-8211270 should be enough? We
> already have CollectedHeap::min_fill_size() to answer the question what
> the min filler size is, so adding a new function doesn't make sense to
> me. What am I missing?

min_fill_size() is static and cannot be overridden by GC. obj_size()
from JDK-8211270 could be used if we'd pass a specific object. I guess
we could make a better abstraction like what Erik suggested in the other
thread:

virtual size_t cell_size(size_t obj_size) { return obj_size; }

and this could be called by JVMT and whitebox (JDK-8211270) with
obj->size(), and by min_fill_size() with the static minimum obj size,
and the GC would translate it to the cell size. The obj_size() from
JDK-8211270 would then be removed and we'd have a single abstraction for
this. Want me to make that change?

Do you agree with the rest of this change? Because there's some
significant changes how TLAB and PLAB calculate their alloc reserves in
there too.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181011/01f1472f/signature.asc>


More information about the hotspot-gc-dev mailing list