JDK-8150239 : Merging information from the ParScanThreadState at the end of GC causes high (unaccounted) pause time costs
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-02-19
  • Updated: 2019-02-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.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
Specjbb2005 (and any other applicaitons run on large heaps and many threads) with 200 worker threads, 50G heap and large young gen size (20G) shows that there is around 50% of pause time outside of actual evacuation that is not accounted for in the "Other" times.

Investigation showed that the problem is initializing the G1ParScanThreadState instances for the worker threads, and then merging the per-thread collected values back later into the global variables. The latter is maybe four times more expensive than the former.
The reasons why this is a problem is that this is an O(#threads * size of collection set) operation, that is done in a single thread.

This CR should deal with improving the PSS information merge phase at the end of the GC. JDK-8150629 is about the initialization phase.
Comments
Not sure if this could also be considered a bug: for some situations this accounts for ~50% of pause time already, sometimes eating up the whole pause goal actually.
19-02-2016