RFR: 8228991: Obsolete -XX:UseAdaptiveGCBoundary

Thomas Schatzl thomas.schatzl at oracle.com
Wed Apr 15 15:23:29 UTC 2020


Hi,

On 15.04.20 16:16, Kim Barrett wrote:
>> On Apr 15, 2020, at 4:49 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> Hi,
>>
>> On 15.04.20 00:23, Kim Barrett wrote:
>>> Please review this change which obsoletes the boolean product flag
>>> -XX:UseAdaptiveGCBoundary and removed the supporting code.
>>> […]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8228991
>>> https://bugs.openjdk.java.net/browse/JDK-8242164 (CSR)
>>> Webrev:
>>> https://cr.openjdk.java.net/~kbarrett/8228991/open.00/
>>> Testing:
>>> mach5 tier1-5.
>>
>>   thanks for tackling this.
>>
>> Found some outdated comments:
> 
> StefanK found some more unnecessary stuff that I’d missed.  In particular, AdjoiningGenerations
> and AdjoiningVirtualSpaces can be removed with a small amount of additional changes.
> [...]
> 
>> - comment in psYoungGen::gen_size_limit() outdated
> 
> Looking at this and similar function in PSOldGen, I think they are now duplicative of other functions
> in the corresponding APIs (PSYoungGen::max_size() and PSOldGen::Max_gen_size()).  More stuff
> I missed.  Stefen didn’t do anything with these in his proposed followup cleanup either.   In order to
> minimize the risk of causing merge collisions with his existing webrev, I think I want to avoid doing
> anything significant in this area with this change. I’ve changed the description though, which now
> matches that of PSYoungGen::max_size().

I considered pointing that out, but in the end refrained from commenting 
further. Okay for deferring further changes to this.

> 
>>> Note: Unable to test nvdimm usage since we don't have any machines
>>> with that configuration.
>>
>> The only related option Parallel GC supports is AllocateHeapAt, and you can pass it any arbitrary file name. I.e. you could test it by specifying a file name in a memory backed directory.
>>
>> Since the impact is only memory reservation, I do not expect a difference though.
> 
> OK, I’ll figure out how to run them that way.
> 
> New webrevs:
> full: https://cr.openjdk.java.net/~kbarrett/8228991/open.01/
> incr: https://cr.openjdk.java.net/~kbarrett/8228991/open.01.inc/
> 
> 

Looks good.

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list