RFR: JDK-8211955: GC abstraction for LAB reserve

[Roman Kennke]

Like this:

Incremental:
http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.03.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.03/

Some notes:
- I was thinking to change min_fill_size() to use cell_size() instead,
but it's used elsewhere as filler-object-size (as opposed to
filler-cell-size)
- I was also thinking to have min_dummy_object_size() use
min_fill_size(), but min_fill_size() returns an aligned size, which is
not what we want there.
- We could keep non-virtual obj_size(oop obj) (or rename it to
cell_size(oop obj) ) and make it use cell_size() instead as little
helper for JVMTI and whitebox, which now do the same thing 2x. WDYT?

How do you like this?

Roman


Am 11.10.18 um 09:45 schrieb Per Liden:
> 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?
> 
> cheers,
> Per

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181011/90b03f67/signature.asc>