On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkem...@openjdk.org> wrote:
> This occurs when an attempt to produce a heap dump conflicts with a > concurrent cycle. The heap dump vm operation attempts to run a cycle directly > on the VM thread with no regard for the state of the concurrent collection. > Although Shenandoah _is_ technically capable of running an entire _full_ GCs > on the vm thread, I would rather not add another dependency on full GCs, nor > would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will > follow the pattern established ZGC in which the calling thread waits for a > concurrent cycle to complete before taking the heap dump. > > ## Testing > > Shenandoh's jtreg test: `gc/shenandoah/TestJcmdHeapDump.java` simply takes a > heap dump of itself. Before this change I observed a failure rate of > approximately 1/6000 executions. The assertion is violated when the VM thread > attempts to run a collection which is not coordinated by Shenandoah's control > thread. This specific assertion happens because the default implementation of > `collect_as_vm_thread` modifies the `_gc_cause` field in ways that Shenandoah > does not expect. Without this assertion, one can only imagine the chaos that > would ensue. This pull request has now been integrated. Changeset: 6a29a811 Author: William Kemper <wkem...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/6a29a8110ec38b4adc8163ba8651cbc935353f1d Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause Reviewed-by: kdnilsen, ysr ------------- PR: https://git.openjdk.org/jdk/pull/23186
