On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long <dl...@openjdk.org> wrote:
>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: >> >>> 308: sp -= 2; >>> 309: sp[-2] = sp[0]; >>> 310: sp[-1] = sp[1]; >> >> This also seems fragile. This seems to depend on an intimate knowledge of >> what the stub will do when returning. We don't need this when doing a >> regular return from the native call, so why do we need it here? I'm >> guessing freeze/thaw hasn't restored the state quite the same way that the >> stub expects. Why is this needed for C2 and not C1? > > Could the problem be solved with a resume adapter instead, like the > interpreter uses? The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485
