RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()

[Dean Long]

On Thu, 22 Aug 2024 05:47:23 GMT, Tobias Hartmann <thartmann 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.

A pin_count overflow/underflow should be a per-thread condition, not global.  If there is nothing in the nmethod to be invalidated, maybe this should be `Action_none`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726482790