JDK-8076462 : Preserving the referents of concurrent mark work distribution method causes long pause times
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-04-01
  • Updated: 2023-08-21
  • Resolved: 2018-05-20
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.
Other
tbd_majorResolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
During reference processing in a gc pause (in G1CollectedHeap::process_discovered_references), we need to preserve (copy) reference objects that were discovered by the concurrent marking reference processor.

We use the G1ParPreserveCMReferentsTask GangTask for that, always executing it using all threads but then internally let some threads just do nothing if there is not enough work to do.

The problem with that method is, if you are on a large machine with tens of threads, and there is almost nothing to do during this phase (or even during the whole GC), starting up and waiting for that many threads takes a very significant fraction of gc pause time, e.g. half of object copy time.

A much better way would be to determine the number of required threads at the outside, and only start up as many threads as required.

Test case: GCOld
Comments
Another example where controlling the number of GC threads would be useful.
08-05-2015