-
Bug
-
Resolution: Fixed
-
P2
-
8, 9
-
b116
-
Verified
- many threads being deactivated although there is still lots of work to do (search for "deactivated worker 51, off threshold 1, current 98")
- many threads activated although there is not much work to do (search for "activated worker 20, on threshold 1, current 2")
- also the number of threads activated is frequently larger than the number of refinement buffers (see attached log, search for "deactivated worker 20, on threshold 1, current 5" where worker 20 is activated when there are only 5 buffers)
This may lead to bad performance (too many threads active, too few active).
The former issue burns CPU time degrading overall performance, the latter impacts regularity of pauses because running too few refinement threads causes refinement buffers to pile up, causing too long pauses.
- relates to
-
JDK-8151670 Unexpected concurrent refinement deactivation and reactivation
- Resolved
-
JDK-8151564 JDK-8150134 broke concurrent refinement thread deactivation
- Closed
-
JDK-8137022 Concurrent refinement thread adjustment and (de-)activation suboptimal
- Resolved
-
JDK-8151594 Move concurrent refinement thread activation logging out of GC pause
- Resolved
-
JDK-8133055 Investigate G1 performance on SPL4
- Closed
-
JDK-8176211 Setting -XX:G1ConcRefinementThreads=0 gives different behavior to using default value of G1ConcRefinementThreads=0
- Closed
-
JDK-8151698 "assert(_process_completed_threshold >= 0) failed: _process_completed is negative" with big G1ConcRefinementGreenZone values on 64 bit JVM
- Resolved