-
Enhancement
-
Resolution: Fixed
-
P3
-
7u80, 8u40, 9
-
b150
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8252048 | openjdk8u272 | Thomas Schatzl | P3 | Resolved | Fixed | b05 |
Large reference arrays cause extremely long synchronization or pause times on both CMS and G1 during marking/pre-cleaning/other tracing related tasks.
The problem is that large reference arrays are not split up into parts during processing, which means that the thread that is currently working on it needs to finish completely before the GC pause can be started.
In G1, run the attached test program with -Xmx14G -XX:+PrintGCDetails -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=50 to see that synchronizing for the safepoint takes extremely long
vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count
829.726: G1IncCollectionPause [ 21 0 0 ] [ 0 0 30576 0 6 ] 0
There is an additional problem: after finishing the marking, at least in the example program there is a guaranteed mark stack overflow, indicating that the marking will never make progress. This may be handled separately.
The problem is that large reference arrays are not split up into parts during processing, which means that the thread that is currently working on it needs to finish completely before the GC pause can be started.
In G1, run the attached test program with -Xmx14G -XX:+PrintGCDetails -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=50 to see that synchronizing for the safepoint takes extremely long
vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count
829.726: G1IncCollectionPause [ 21 0 0 ] [ 0 0 30576 0 6 ] 0
There is an additional problem: after finishing the marking, at least in the example program there is a guaranteed mark stack overflow, indicating that the marking will never make progress. This may be handled separately.
- backported by
-
JDK-8252048 Large reference arrays cause extremely long synchronization times
- Resolved
- blocks
-
JDK-8168467 Use TaskEntry as task mark queue elements
- Resolved
- duplicates
-
JDK-8066387 G1GC induces 3s GC pause when JVM is asked to exit
- Closed
-
JDK-8154221 Long pauses of application threads caused by VMThread and concurrent mark of large array
- Closed
- relates to
-
JDK-8159422 Very high Concurrent Mark mark stack contention
- Resolved