JDK-8228991 : Obsolete -XX:UseAdaptiveGCBoundary
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9,11,12,13,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-08-01
  • Updated: 2020-08-12
  • Resolved: 2020-04-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b20Fixed
Related Reports
CSR :  
JDK-8242164 - Obsolete -XX:UseAdaptiveGCBoundary
Relates :  
JDK-8242901 - Duplicate PSYoung/OldGen max size functions
Relates :  
JDK-8243146 - Further cleanups after UseAdaptiveGCBoundary removal
Sub Tasks
JDK-8242903 :  
Release Note: Obsolete -XX:UseAdaptiveGCBoundary - Closed
Description
Running parallel gc with -XX:+UseAdaptiveGCBoundary causes random crashes.

A good reproducer is
jdk/bin/jaotc -J-XX:+UseParallelGC -J-XX:+UseAdaptiveGCBoundary -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC -J-XX:CompileCommand=compileonly,NO.COMPILATIONS -J-XX:-UseCompressedOops -J-ea -J-esa --compile-with-assertions --info --output Test.so --class-name java.util.ArrayList 

Depending on the machine -J-XX:-UseParallelOldGC may help in reproducing the issue.

Further information in the comments as this is a bug that has initially been reported
Comments
Verified -XX:+UseAdaptiveGCBoundary is reported as obsolete. Ran the crash reproducer 20 times without failure, where before it would crash pretty frequently.
12-08-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a48c2df5440b User: kbarrett Date: 2020-04-18 03:23:28 +0000
18-04-2020
There is an old email thread suggesting there may be performance problems with using this flag (presumably it wasn't causing crashes at some point) and recommending against using it: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-February/004058.html The default for this flag was set to true by JDK-6206493 (resolved 2005-03-16), but then set back to false by JDK-6226008 (resolved 2005-03-16, so nearly immediately if the JBS timestamps can be trusted, though I think they can't) because it was causing crashes. Also some discussion in JDK-6247684 of a performance regression.
22-02-2020
This code has been broken for forever, so strongly consider starting the deprecation/obsoletion process in 15. Too late to do this for 14, and there would be a lot of code to remove.
04-12-2019
I get reproducible VerifyAfterGC failures with the reproducer in the description (which is implicitly using the default -XX:+UseParallelOldGC). The verification failures happen in StringTable::verify, but that's just because it's one of the early verifier steps. If I move it to the end of Universe::verify then I get failures in ClassLoaderData::verify. Using -XX:-UseParallelOldGC, I instead get crazy random crashes in the application rather than verification failures. With -XX:-UseAdaptiveGenerationSizePolicyAtMajorCollection (suggested by Thomas) I get no failures with either oldgen collector. Reproducibility might be related to ergonomics. On the machine I'm testing with, I get a max heap size of 8417968128 and 18 GC threads.
01-08-2019
JDK13 Defer request justification: We are very late in JDK13 process as this issue showed up. This is not a regression as all JDK version since ~8u60 (see referenced JI-9041983) are affected; apparently this is not a very often used GC flag either, so there this does not seem to be a significant loss in functionality.
01-08-2019