RFR: 8228991: Obsolete -XX:UseAdaptiveGCBoundary

[Thomas Schatzl]

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.
> 
> As discussed in the associated CSR, this feature has had a long bug
> tail and does not appear to have ever really worked, so we're going
> straight to obsoleting the option and removing the code, rather than
> first deprecating it.
> 
> This mostly involves removal of a bunch of code.  In some places there
> are functions which previously needed to be virtual but no longer need
> that because the derived classes no longer exist.
> 
> There is an assertion in ParallelScavengeHeap::initialize() that was
> changed by removing !UseAdaptiveGCBoundary from a disjunction, which
> is not what one would expect if making that option unconditionally
> false.  It looks like the presence of a test for that option never
> mattered, as except in the heterogeneous heap case the virtual spaces
> have always supposed to meet (it's using AdjoiningGenerations after
> all) and did so.
>   
> 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:

- maybe add a release note for this to get some more publicity of that 
change (if we want it)

- adjoiningenerations.hpp:36: s/down/done (pre-existing)

- in the same paragraph, I think the last sentence referes to moving the 
boundary and should be removed.

- adjoiningVirtualSpaces.hpp: the comment at the beginning of the file 
also refers to moving the boundary.

- PSGCAdaptivePolicyCounters::_boundary_moved and related code is 
obsolete now

- outdated comment for PSScavenge::set_young_generation_boundary (both 
in hpp and cpp file)

- comment in psYoungGen::gen_size_limit() outdated

 > 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.

Thanks,
   Thomas


-