JDK-8140597 : Forcing an initial mark causes G1 to abort mixed collections
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-10-27
  • Updated: 2015-11-29
  • Resolved: 2015-11-11
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 9
9 b94Fixed
Related Reports
Blocks :  
JDK-8136678 - Implement adaptive sizing algorithm for IHOP
Duplicate :  
JDK-8141402 - GC locker initiated GC ends mixed gc phase
Relates :  
JDK-8140689 - Skip last young-only gc if nothing to do in the mixed gc phase
Description
If an initial mark is caused by humongous allocations, the gc locker or the metadata threshold being surpassed, the mixed gc phase is interrupted.

This means that potentially no mixed gc will ever happen in many cases, running into full gcs all the time.
Comments
Skipping due to humongous object alloction happens regularly on the ArrayJuggle tests, e.g. "gc.ArrayJuggle.Juggle01.Juggle01 -gp shortArr -ms high" when run in slowdebug mode. Humongous object allocations cause a collection with _g1_humongous_allocation cause, issuing a VM_G1IncCollectionPause with should_initiate_conc_mark true, which then calls G1CollectorPolicy::force_initial_mark_if_outside_cycle() which sets CollectorState::_initiate_conc_mark_if_possible. In G1CollectorPolicy::decide_on_conc_mark_initiation(), in the last young gc before mixed gc, "during_cycle" may be false (because it is the "during marking state" of the ConcurrentMark class), forcing an initial mark. Initial mark then prevents starting the mixed gc phase, aborting with a "concurrent cycle is about to start" message. This can go on perpetually if the application allocates a humongous object that triggers an inital mark request between the time the ConcurrentMark class thinks the concurrent cycle ended and the last young gc before the mixed gc phase. I think the calculation of during_cycle in G1CollectorPolicy::decide_on_conc_mark_initiation() is wrong.
05-11-2015
A test for the situation occuring due to GClocker is gc/lock/jni/jnilock002.
04-11-2015
Added the "blocks JDK-8136678" reference because starting marking at the last possible time typically guarantees either a long evacuation failure or full gc if mixed gc does not occur.
27-10-2015
I remember at least one mail on hotspot-gc-use where we could not explain why mixed gcs were not starting in time sometimes.
27-10-2015
History: This is a bug probably in the code since 2010.
27-10-2015
Suggested ILW: Impact = M, may cause full gcs (major performance issue), Likelihood = M (depends on the application and timing), Workaround = H (none) -> P3 (potentially P2)
27-10-2015