RFR: JDK-8211955: GC abstraction for LAB reserve
Per Liden
per.liden at oracle.com
Thu Oct 11 07:45:05 UTC 2018
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
More information about the hotspot-gc-dev
mailing list