JDK-8065227 : Report allocation context stats at end of cleanup
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-11-18
  • Updated: 2015-06-03
  • Resolved: 2014-11-21
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 8 JDK 9
8u40 b16Fixed 9Fixed
Sub Tasks
JDK-8065228 :  
HeapMetricTest stability fixes - Resolved
Description
Currently the allocation context stats are reported at the end of remark. Moving the report to the clean-up phase will enable us to better avoid triggering new marking cycles to early.
Comments
Making this confidential due to talk about resource management. As far as I know this bug is unrelated to the bug Jenny filed. This is for resource management to be able to have better control over when a new marking cycle is initiate. Previously we posted the results during remark which then was notified by the JDK API to the user. When the user got these values it might make sense to him to request a new marking cycle, but we sometimes blocked this request because ConcurrentMarkThread::during_cycle() could still return true, since it's not reset until the very end of the cycle. Moving the reporting to the cleanup phase made it possible to use G1CollectedHeap::mark_in_progress() as the condition instead, here's part of the closed change: - if (!g1h->concurrent_mark()->cmThread()->during_cycle()) { + // Only initiate a new marking cycle if not currently running one or + // if the current one has been aborted. + if (!g1h->mark_in_progress() || g1h->concurrent_mark()->has_aborted()) { With this change in place the user of the API will now safly be able to request new data when the retrieve the current, but the basics around triggering of a new cycle still applies, so if the user does the request whilst during_cycle() is still true, the request will get stalled until it is possible to satisfy it. This could of course have been achieved by adding a new state saying that remark is done, but that would further complicate the states diagram and also force us to stall potential new requests for a longer time.
20-11-2014
Can you explain the how the triggering of a new marking cycle is affected? Also does this have anything to do with https://bugs.openjdk.java.net/browse/JDK-8065402 ? I noted that reset_marking_stack() will now be done later.
20-11-2014