-
Bug
-
Resolution: Fixed
-
P4
-
21, 22, 23, 24
-
b19
Immediately following certain GC safepoints (Final Mark and Final update refs), the GC contends aggressively for the heap lock with multiple mutator threads, each of which needs the heap lock in order to replenish its TLAB.
A certain AWS service which runs with 32 physical cores, over 2,000 ready-to-run mutator threads, and a typical collection set of over 2,000 regions (all of which must be recycled at the end of Final Update Refs), has identified this contention for locks as a key cause for higher-than-desired latency.
Careful batching of regions allows significant improvement to the efficiency of this contended lock resolution, which is manifest in much improved latency of customer metrics.
A certain AWS service which runs with 32 physical cores, over 2,000 ready-to-run mutator threads, and a typical collection set of over 2,000 regions (all of which must be recycled at the end of Final Update Refs), has identified this contention for locks as a key cause for higher-than-desired latency.
Careful batching of regions allows significant improvement to the efficiency of this contended lock resolution, which is manifest in much improved latency of customer metrics.
- links to
-
Commit(master) openjdk/jdk/f5f0852f
-
Commit(master) openjdk/shenandoah-jdk21u/e7ff0377
-
Review(master) openjdk/jdk/21211
-
Review(master) openjdk/shenandoah-jdk21u/119