|
Quick Lists
|
|
Bug ID:
|
6865703
|
|
Votes
|
0
|
|
Synopsis
|
G1: parallelize cache clean up
|
|
Category
|
hotspot:garbage_collector
|
|
Reported Against
|
|
|
Release Fixed
|
hs16(b08),
6u18(b01) (Bug ID:2181948)
, 7(b71) (Bug ID:2182204)
|
|
State
|
11-Closed,
Unverified,
request for enhancement
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
6866330
|
|
Submit Date
|
28-JUL-2009
|
|
Description
|
When running performance tests with large heaps (24G or so) I noticed that GC worker 0 was taking longer in the RS updating phase than the rest. Here's an example:
[Update RS (ms): 4.6 2.3 2.4 2.6 2.3 2.4 2.5 2.7 2.2 2.6 2.6 2.4 2.3
Avg: 2.6, Min: 2.2, Max: 4.6]
When the pause times were short, this resulted in long termination times for all but worker 0:
[Termination (ms): 0.0 2.0 1.9 1.9 2.0 1.9 1.9 1.9 1.9 1.9 2.0 1.9 1.9
Avg: 1.8, Min: 0.0, Max: 2.0]
which added unnecessary time to the collection pause.
Posted Date : 2009-07-28 15:29:15.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
The bottleneck is the worker 0 alone serially cleans up the card cache. And if that processing takes a non-trivial amount of time, then the rest might have to wait for it during termination.
Posted Date : 2009-07-28 15:29:15.0
http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/15c5903cf9e1
Posted Date : 2009-08-04 09:45:29.0
http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15c5903cf9e1
Posted Date : 2009-08-06 03:40:44.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
|
