Skip to content

YJIT: omit single ractor mode assumption for proc#call#15092

Merged
luke-gru merged 1 commit intoruby:masterfrom
luke-gruber:yjit_optimized_method_type_call_ractor_mode
Nov 18, 2025
Merged

YJIT: omit single ractor mode assumption for proc#call#15092
luke-gru merged 1 commit intoruby:masterfrom
luke-gruber:yjit_optimized_method_type_call_ractor_mode

Conversation

@luke-gruber
Copy link
Contributor

The comptime receiver, which is a proc, is either shareable or from this ractor so we don't need to assume single-ractor mode. We should never get the "defined with an un-shareable Proc in a different ractor" error.

@matzbot matzbot requested a review from a team November 7, 2025 02:44
@k0kubun
Copy link
Member

k0kubun commented Nov 7, 2025

Is it possible to add a test in test_yjit.rb (either bootstraptest/ or test/ruby/) that used to fail with "defined with an un-shareable Proc in a different ractor" but now doesn't? Are we already testing it somewhere, or was the error never a thing?

@luke-gruber
Copy link
Contributor Author

I don't think it was ever possible.

@luke-gru luke-gru requested a review from jhawthorn November 7, 2025 18:50
Copy link
Member

@XrXr XrXr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasoning is sound to me. Calling a proc is not something that inherently has the possibility of crossing ractor boundary, so unless the isolation is already broken by some other means (like in https://bugs.ruby-lang.org/issues/21649), this is fine.

I'd like to add a test that does method(:a_unshareable_bmethod).to_proc.call, if there isn't one, though. I think we added this check in YJIT because the bmethod calling code is reachable this way. It's fine because Method#to_proc wraps the internal bmethod proc, so isn't an alternative way to call bmethods.

@luke-gruber luke-gruber force-pushed the yjit_optimized_method_type_call_ractor_mode branch from dab46d3 to e3ec47e Compare November 18, 2025 14:13
The comptime receiver, which is a proc, is either shareable or from this
ractor so we don't need to assume single-ractor mode. We should never get
the "defined with an un-shareable Proc in a different ractor" error.
@luke-gruber luke-gruber force-pushed the yjit_optimized_method_type_call_ractor_mode branch from e3ec47e to 5a42f25 Compare November 18, 2025 14:15
@luke-gru luke-gru merged commit ff2d2fc into ruby:master Nov 18, 2025
89 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants