JDK-7102445 : G1: Unnecessary Resource allocations during RSet scanning
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7u2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-10-18
  • Updated: 2013-09-18
  • Resolved: 2012-01-23
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 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-7096030 - G1: PrintGCDetails enhancements
Description
During some large benchmark runs - notably the ATG CRM demo - some inconsistencies were seen inthe PrintGCDetails output between the global Pallel Other time (the interval from when all workers are started to when all workers have finished) and the per-worker parallel time (the duration of the worker's work() method). The timings were consistently around 35-37ms.

We suspect this is because some destructors are executed at the end of the work() method and outside the timing scope. We should fix that and make sure that those two measurements are consistent.
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c6a6e936dc68
10-11-2011
EVALUATION See main CR
04-11-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c6a6e936dc68
24-10-2011
SUGGESTED FIX Stack allocate the DirtyCardToOopClosure instance in ScanRSClosure::scanCard.
18-10-2011
EVALUATION An instance of a DirtyCardToOopClosure was being resource allocated for every card scanned during RSet scanning. While freeing the Chunks to the ChunkPools, upon execution of the ResourceMark desctructor, the GC worker threads were contending on the pthread mutex that is utilized by the ThreadCritical object.
18-10-2011