RFR: 8340400: Shenandoah: Whitebox breakpoint GC requests may cause assertions
William Kemper
wkemper at openjdk.org
Thu Sep 19 17:57:38 UTC 2024
On Wed, 18 Sep 2024 21:02:23 GMT, William Kemper <wkemper at openjdk.org> wrote:
> When a test requests a concurrent GC breakpoint, the calling thread arranges for itself to block until the concurrent GC thread notifies it that the GC has reached the requested breakpoint (phase). The code that handles the whitebox breakpoint request should therefore not block the caller. An attempt was made to do this, but the request just has the caller thread run in a busy loop without waiting. What's more, this loop resets the requested gc cause on every iteration, which may lead to gc cycles with a wb_breakpoint cause, but no breakpoint set - which violates assertions.
TestReferenceShortcutCycle and TestReferenceRefersToShenandoah would fail occasionally in the generational mode. I believe the generational mode was more susceptible to the issue because of differences in the generational mode controller. I don't recall seeing test failures in upstream, but as I read the code I believe the issue _could_ happen to other Shenandoah modes (or otherwise cause tests using whitebox breakpoints to behave in unexpected ways).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21074#issuecomment-2361831211
More information about the hotspot-gc-dev
mailing list