RFR: 8263375: Support stack watermarks in Zero VM

[Erik Österlund]

On Thu, 8 Jul 2021 16:48:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero VM supports most of GCs. Since JDK 16, Shenandoah uses stack watermarks, so Zero has to support those if Shenandoah+Zero support is to remain. This PR adds the stack watermark support in Zero VM. This should also be useful as other projects, notably Loom, mature and depend on stack watermarks.
> 
> Zero already calls into Hotspot safepoint machinery to do things, and it seems only the hooks for `on_iteration` and `on_unwind` are missing. AFAICS, Zero only has on-return safepoints, renamed it to be more precise.
> 
> @fisk, do you see any obvious problems with this patch?
> 
> Additional testing:
>  - [x] Linux x86_64 Zero `hotspot_gc_shenandoah` now passes

Looks good in general, would just like slightly more precise hooks as explained in a comment above. It will probably work without that though.

src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 205:

> 203:     // Notify the stack watermarks machinery that we are unwinding.
> 204:     // Should do this before resetting the frame anchor.
> 205:     stack_watermark_unwind_check(thread);

I wonder if this should maybe move down a bit to where we inspect the reason we left the interpreter loop. There are multiple reasons and only some involve unwinding. I'm thinking BytecodeInterpreter::return_from_method and BytecodeInterpreter::do_osr

Regarding BytecodeInterpreter::throwing_exception the current contract for exception handing is that an unwind handler is called *after* unwinding instead. We have some exception handler function in the interpreter runtime that gets called after unwinding with an exception into an interpreted frame. Hopefully that still gets called when using zero. Worth double checking.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4728