-
Bug
-
Resolution: Unresolved
-
P4
-
26
From mail.openjdk.org/pipermail/hotspot-gc-dev/2025-September/055035.html:
"I'm observing an interesting regression between build 26-ea+16-1649 and
build 26-ea+17-1764 with respect to concurrent refinement. I suspect the
cause is JEP 522.
I ran a stress test in which GC pauses are about 25ms in the steady
state. With 26-ea+16-1649, concurrent refinement is never initiated.
With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the test
has run for a few minutes. Eventually, concurrent refinement runs back
to back forever, wasting a CPU core and affecting overall performance."
GC logs before ("baseline") and after ("changes") are attached.
"I'm observing an interesting regression between build 26-ea+16-1649 and
build 26-ea+17-1764 with respect to concurrent refinement. I suspect the
cause is JEP 522.
I ran a stress test in which GC pauses are about 25ms in the steady
state. With 26-ea+16-1649, concurrent refinement is never initiated.
With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the test
has run for a few minutes. Eventually, concurrent refinement runs back
to back forever, wasting a CPU core and affecting overall performance."
GC logs before ("baseline") and after ("changes") are attached.
- relates to
-
JDK-8368946 G1: Improve refinement thread activation
-
- New
-
-
JDK-8342382 Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization
-
- Resolved
-