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