RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin() [v3]
Dean Long
dlong at openjdk.org
Thu Aug 22 19:51:07 UTC 2024
On Thu, 22 Aug 2024 15:50:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>> It is updated to use Action::none to keep the nmethod. The trap code picks up the correct bytecode (invokestatic) from the trap scope. So after unrolling the host method (the inliner), the trap bytecode (i.e., the invokestatic call to Continuation.pin() or unpin()) is re-executed in the interpreter. This is also without setting the explicit re-execute state (which may mean something else).
>
> Yes, we should not throw out compiled nmethod if one thread need to got into Interpreter and throw an exception.
> Other threads will continue to use this nmethod.
> This is also without setting the explicit re-execute state (which may mean something else).
I think reexecute is implicitly set for uncommon traps, and the explicit flag is for deoptimization safepoints.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1727725892
More information about the core-libs-dev
mailing list