RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]
Dean Long
dlong at openjdk.org
Mon Oct 28 19:07:47 UTC 2024
On Sat, 26 Oct 2024 06:56:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>>
>>> 1565:
>>> 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor.
>>> 1567: bind(resume_pc);
>>
>> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?
>
> The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.
>
> At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.
OK, that makes sense now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366
More information about the graal-dev
mailing list