RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()
Tobias Hartmann
thartmann at openjdk.org
Thu Aug 22 05:52:09 UTC 2024
On Wed, 21 Aug 2024 20:11:05 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
> Greetings,
>
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
>
> Testing: jdk_jfr, loom testing
>
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
>
> Thanks
> Markus
src/hotspot/share/opto/library_call.cpp line 3787:
> 3785: set_all_memory(input_memory_state);
> 3786: uncommon_trap_exact(Deoptimization::Reason_intrinsic,
> 3787: Deoptimization::Action_reinterpret);
Why do you use `Action_reinterpret` and not `Action_make_not_entrant` here?
You may need a check to avoid endless re-compilation of a method that always hits the trap:
if (too_many_traps(Deoptimization::Reason_intrinsic)) {
return false;
}
See other intrinsics.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726376702
More information about the core-libs-dev
mailing list