Assert during stackwalk

[Ron Pressler]

I don’t recall us changing anything about how StackWalker interacts with the stack watermark. Can you change the Fuzz test so
that it doesn’t use continuations and see if this reproduces in mainline?

— Ron

> On 8 Feb 2021, at 16:58, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Hello again,
> 
> I think I have now implemented the proper parts for Shenandoah GC in ShHeap::requires_barriers() now (will send PR shortly) and now I'm hitting another problem: the Fuzz.java test throws an assertion at me (when running in Shenandoah aggressive mode, which does a *lot* of GC work):
> 
> #  Internal Error (/home/rkennke/src/openjdk/loom/src/hotspot/share/runtime/stackWatermark.cpp:178), pid=54418, tid=54534
> #  assert(is_frame_safe(f)) failed: Frame must be safe
> 
> The full hs_err:
> http://cr.openjdk.java.net/~rkennke/hs_err_pid54418.log
> 
> It looks to me that the stackwalk uses the stack watermark mechanism, and this conflicts with Shenandoah's own use of the stack watermark to concurrently update thread roots during the evacuation phase. Am I missing some necessary coordination there?
> 
> (Also, is this all Loom tests, or should I also run other tests too?
> 
> make run-test TEST=java/lang/Continuation TEST_VM_OPTS="-XX:+UnlockDiagnosticVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive"
> 
> )
> 
> Thanks,
> Roman
>