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