JDK-8195158 : Concurrent System.gc() is "upgraded" to stop-the-world System.gc()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-01-16
  • Updated: 2021-06-08
  • Resolved: 2018-01-19
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 11
11 b01Fixed
Related Reports
Relates :  
JDK-8268390 - G1 concurrent gc upgrade to full gc not working
Description
assert(!GCCause::is_user_requested_gc(gc_cause()) || explicit_gc) failed: invariant

V  [libjvm.so+0xb3e62d]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.so+0xcc069d]  G1CollectedHeap::verify_before_full_collection(bool)+0x4d
V  [libjvm.so+0xd078f1]  G1FullCollector::prepare_collection()+0x51
V  [libjvm.so+0xccc396]  G1CollectedHeap::do_full_collection(bool, bool)+0x166
V  [libjvm.so+0x1877b55]  VM_G1CollectForAllocation::doit()+0x345
V  [libjvm.so+0x1875438]  VM_Operation::evaluate()+0x208
V  [libjvm.so+0x187128e]  VMThread::evaluate_operation(VM_Operation*)+0x16e
V  [libjvm.so+0x1871e12]  VMThread::loop()+0x2e2
V  [libjvm.so+0x1872610]  VMThread::run()+0xc0
V  [libjvm.so+0x14c04ba]  thread_native_entry(Thread*)+0xfa
Comments
Patch (including regression test): http://cr.openjdk.java.net/~ehelin/JDK-8195158/00/index.html Review email thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-January/021092.html
17-01-2018
As for the priority, this would not be a crash in product mode (if an assert failure is a crash is debug mode is debatable). However, this would be a performance problem in production code, since we might run too many stop-the-world compacting full GC (maybe the cleanup phase of the concurrent mark cycle is enough). For likelihood, this only happens when there are not a single free region left *and* a user runs System.gc() *and* -XX:+ExplicitGCInvokesConcurrent is set. The workaround would be to run without -XX:+ExplicitGCInvokesConcurrent (rather intrusive workaround).
17-01-2018
Yes, JDK-8137099 did introduce this problem. The issue happens when the heap is full *and* System.gc() is called *and* -XX:+ExplicitGCInvokesConcurrent is true. This causes the 'concurrent user initiated full GC' to be "upgraded" to a blocking STW full GC. This manifests itself is the code as the cause being GCCause::_java_lang_system_gc and the explicit_gc being false. The fix (which is being worked on) is to not upgrade user initiated GCs that are supposed to be concurrent.
17-01-2018
It seems like JDK-8137099 introduced this problem.
16-01-2018