| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8083051 | emb-9 | Marcus Larsson | P4 | Resolved | Fixed | b34 |
| JDK-8086449 | 8u65 | Marcus Larsson | P4 | Resolved | Fixed | b01 |
| JDK-8076064 | 8u60 | Marcus Larsson | P4 | Resolved | Fixed | b09 |
| JDK-8137601 | emb-8u65 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8077464 | emb-8u60 | Marcus Larsson | P4 | Resolved | Fixed | team |
At GC time G1 needs to flush the hot card cache. This is done in parallel using a (too) simple mechanism to chunk the whole hot card cache into parts:
In detail, the chunk size is
hot card cache chunk size = size of hot card cache / number of threads
Which is too coarse for moderately large hot card cache sizes: it happens that in some applications one thread may delay all other threads significantly because it got quite late to processing the (large) hot card cache.
The change can be tested by e.g. setting G1ConcRSLogCacheSize to 20.
The fix could be to bound the hot card cache chunk size, or even more simple fix it to some reasonable size.
In detail, the chunk size is
hot card cache chunk size = size of hot card cache / number of threads
Which is too coarse for moderately large hot card cache sizes: it happens that in some applications one thread may delay all other threads significantly because it got quite late to processing the (large) hot card cache.
The change can be tested by e.g. setting G1ConcRSLogCacheSize to 20.
The fix could be to bound the hot card cache chunk size, or even more simple fix it to some reasonable size.
- backported by
-
JDK-8076064 Hot card cache flush chunk size too coarse grained
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-