JDK-8004888 : G1: PSR large heap case shows steady increase in ART
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23.5,hs25
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2012-12-11
  • Updated: 2015-08-17
  • Resolved: 2015-08-17
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
9Resolved
Related Reports
Relates :  
JDK-7145569 - G1: optimize nmethods scanning
Relates :  
JDK-6490401 - Avoid unnecessary system dictionary scanning during young GCs
Relates :  
JDK-8015237 - Parallelize string table scanning during strong root processing
Relates :  
JDK-8003420 - NPG: make new GC root for pd_set
Description
PSR ran with ParOld and G1 and saw ARTs of ~1.15secs and 10.85secs respectively. After plotting the max and average times for the sub-tasks for all pauses for G1GC, I noticed that termination times were following the steady increase in pause time trend and high (single) external root scan time was the reason why.

A plausible cause could be code cache scanning by a single thread during each pause. For ParOld, I think its alleviated due to the frequent full GCs that cause class unloading.

After discussing this with John C2, there are a couple of things that can be done:
1) Add claiming mechanism such that the code cache is not treated as a single root.
2) There is already a CR for G1 that could help this case for G1: http://bugs.sun.com/view_bug.do?bug_id=7145569
Comments
Numbers looked good in 8u20, so no longer an issue
17-08-2015
I have updated a patch for JDK-8003420 which may help with this issue: http://cr.openjdk.java.net/~iklam/8003420/dict_pd_set_002/ It reduces scanning time of system dictionary (in Ext Root Scanning). I have added diagnostic messages that can show the number of class loaders and protection domain objects that need to be scanned. Please run the PSR tests with "-XX:+PrintGCDetails -XX:+Verbose" and grep for "oops_do" in the GC log. When I tested with bigapps/Weblogic+medrec, I can see that the numbers will eventually level off (905 loaders and 372 protection domains). 976.051: [GC pause (G1 Evacuation Pause) (young)ProtectionDomainCacheTable::oops_do 372 objects, allref: 9708, maxref: 1644 ClassLoaderDataGraph::oops_do 905 loaders 977.765: [GC pause (G1 Evacuation Pause) (young)ProtectionDomainCacheTable::oops_do 372 objects, allref: 9708, maxref: 1644 ClassLoaderDataGraph::oops_do 905 loaders 979.414: [GC pause (G1 Evacuation Pause) (young)ProtectionDomainCacheTable::oops_do 372 objects, allref: 9708, maxref: 1644 ClassLoaderDataGraph::oops_do 905 loaders 981.117: [GC pause (G1 Evacuation Pause) (young)ProtectionDomainCacheTable::oops_do 372 objects, allref: 9708, maxref: 1644 ClassLoaderDataGraph::oops_do 905 loaders I want to see how big these two numbers eventually become in the PSR runs. Thanks!
18-07-2013