RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin() [v2]
Markus Grönlund
mgronlun at openjdk.org
Thu Aug 22 11:24:05 UTC 2024
On Thu, 22 Aug 2024 09:24:18 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
>> The pattern of the uncommon trap construct was taken from the precedent in LibraryCallKit::inline_profileBoolean().
>
> Is it an implicit invariant that execution always continues in the interpreter after an uncommon trap? I.e., I don't need to explicitly tell it to "re-execute" there?
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).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726868890
More information about the core-libs-dev
mailing list