-
Enhancement
-
Resolution: Not an Issue
-
P3
-
hs23.5, hs25
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
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
- relates to
-
JDK-7145569 G1: optimize nmethods scanning
-
- Resolved
-
-
JDK-8003420 NPG: make new GC root for pd_set
-
- Resolved
-
-
JDK-8015237 Parallelize string table scanning during strong root processing
-
- Resolved
-
-
JDK-6490401 Avoid unnecessary system dictionary scanning during young GCs
-
- Closed
-