JDK-8220290 : gc_epilogue(full = false) is called on Full GC path after JDK-8215221
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-07
  • Updated: 2019-03-14
  • Resolved: 2019-03-08
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 13
13 b12Fixed
Related Reports
Relates :  
Description
gc/arguments/TestSurvivorRatioFlag.java fails after JDK-8215221 with Serial GC with

# after -XX: or in .hotspotrc:  SuppressErrorAt=/defNewGeneration.cpp:892
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/07fc96ef-bf4d-487f-b22f-a84e49f5f44a-S31990/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2a60951b-36cf-4d2a-a452-7fcb424f7be8/runs/0b75d738-322f-4c76-83d3-db93a0ee84b4/workspace/open/src/hotspot/share/gc/serial/defNewGeneration.cpp:892), pid=27280, tid=27288
#  assert(gch->gc_cause() == GCCause::_scavenge_alot || (GCCause::is_user_requested_gc(gch->gc_cause()) && UseConcMarkSweepGC && ExplicitGCInvokesConcurrent) || !gch->incremental_collection_failed()) failed: Twice in a row
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-jdk13-jdk.547)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-jdk13-jdk.547, mixed mode, sharing, tiered, compressed oops, concurrent mark sweep gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xa3afdc]  DefNewGeneration::gc_epilogue(bool)+0x34c
#
# Core dump will be written. Default location: [...]
#
Unsupported internal testing APIs have been used.


Comments
RFR: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-March/025000.html
07-03-2019

I think I know why, look here: http://cr.openjdk.java.net/~shade/8215221/webrev.03/src/hotspot/share/gc/shared/genCollectedHeap.cpp.sdiff.html The old shared path was: 647 // Update "complete" boolean wrt what actually transpired -- 648 // for instance, a promotion failure could have led to 649 // a whole heap collection. 650 complete = complete || collected_old; ... 673 gc_epilogue(complete); In the new path, I put gc_epilogue(complete) in the separate full-gc path. But, collected_old used to be "true" there, which necessarily turned "complete" to "true" too. In new code, this does not happen, and we can call gc_epilogue(complete [false]). Should be gc_epilogue(true) on that path, I think. CMS assert fails inside gc_epilogue(...) on "full = false" path.
07-03-2019

Yup, this apparently fixes it: diff -r ff399127078a src/hotspot/share/gc/shared/genCollectedHeap.cpp --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp Thu Mar 07 15:27:42 2019 +0100 +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp Thu Mar 07 17:31:28 2019 +0100 @@ -677,11 +677,13 @@ MetaspaceUtils::print_metaspace_change(metadata_prev_used); // Track memory usage and detect low memory after GC finishes MemoryService::track_memory_usage(); - gc_epilogue(complete); + // Need to tell the epilogue code we are done with Full GC, regardless what was + // the initial value for "complete" flag. + gc_epilogue(true); BiasedLocking::restore_marks(); print_heap_after_gc(); }
07-03-2019

Reproduced locally after a few tries with: $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=gc/arguments/TestSurvivorRatioFlag.java TEST_VM_OPTS="-XX:+UseConcMarkSweepGC"
07-03-2019

Cannot reproduce locally with: $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=gc/arguments/TestSurvivorRatioFlag.jav Would you mind attaching full hs_err?
07-03-2019