On Wed, 4 Sep 2024 11:55:50 GMT, Jorn Vernee wrote:
>> It does return. `ShouldNotReachHere` is used to crash the VM.
>
> `fatal()` might be better here. I could change it.
Yes please do.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1745356400
On Wed, 4 Sep 2024 16:45:38 GMT, Amit Kumar wrote:
>> I looked into it, but couldn't find out. But I remove the `save_return_pc` &
>> `restore_return_pc` and everything seems fine. So maybe we can remove it.
>
> Tier1 test are fine with/without "saving & restoring" return_pc;
I found it:
https
On Wed, 4 Sep 2024 10:00:47 GMT, Martin Doerr wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add RISC-V as target platform
>
> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062:
>
>> 3060: StubCodeMark mar
On Wed, 4 Sep 2024 16:45:04 GMT, Amit Kumar wrote:
>> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062:
>>
>>> 3060: StubCodeMark mark(this, "StubRoutines",
>>> "upcall_stub_load_target");
>>> 3061: address start = __ pc();
>>> 3062: __ save_return_pc();
>>
>> @offamitkumar: I
On Wed, 4 Sep 2024 13:14:55 GMT, Jorn Vernee wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upcal
On Wed, 4 Sep 2024 12:46:21 GMT, Fei Yang wrote:
>> Were you able to reproduce the original issue on RISC-V?
>
>> Were you able to reproduce the original issue on RISC-V?
>
> Yeah. I can reproduce similar crash on linux-riscv64 platform running this
> new test as well.
Ok, I'll add riscv as on
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time when the upcall stub is generated. The MH
> instance itself is stashed i
