RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames

[Fredrik Bredberg]

On Mon, 31 Jul 2023 07:40:16 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> I've done basic loom testing on ppc64le and riscv64 using Qemu, but would appreciate if @reinrich and @RealFYang could take it for a real test drive.
>> 
>> PPC code looks good. I've tested `jtreg:test/jdk/jdk/internal/vm/Continuation` successfully. Will do more testing until monday.
>
>> > I've done basic loom testing on ppc64le and riscv64 using Qemu, but would appreciate if @reinrich and @RealFYang could take it for a real test drive.
>> 
>> PPC code looks good. I've tested `jtreg:test/jdk/jdk/internal/vm/Continuation` successfully. Will do more testing until monday.
> 
> So there are crashes in our tests with this pr applied.
> E.g. `make test TEST=runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java` crashes always. To me it seems that the issue is unrelated to virtual threads. It has to be caused by relativization of `top_frame_sp`
> Unfortunately I cannot look into it since I'm actually on vacation. @TheRealMDoerr might want to look into it. He's coming back from vacation in a couple of days.

Thank you @reinrich for pointing out the failing `runtime/CommandLine/OptionsValidation/TestOptionsWithRangesDynamic.java` test. I used `R11_scratch1` inside `InterpreterMacroAssembler::add_monitor_to_stack()` which apparently is not so good because it's the same register as is used for the local `esp` register. Since `R12_scratch2` is also used I looked around the code and figured I should be able to  use `R23_tmp3` as a scratch register. It seems to work. Now the test passes.

Do you or @TheRealMDoerr have any objections to using `R23_tmp3` as a scratch register in `InterpreterMacroAssembler::add_monitor_to_stack()` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1659258467