YJIT: gen_set_ivar cache ivar index for types other than T_OBJECT #14399
+54
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While writing into ivars of other types is too complicated to realistically generate the ASM for it, we can at least provide the ivar index as to not have to lookup the shape tree every time.
The
vm_ivar_set_on_class
case is still noticeably slower thanvm_ivar_set_on_instance
becauserb_ivar_set_at
performs ractor checks. We could bypass them withassume_single_ractor_mode
to acheived ~2.2x the baseline.Then it's also noticeably slower because the benchmark sets immediate and YJIT skip triggering write barriers for those, but
RB_OBJ_WRITE
always does. If we skip the write barrier we end up at ~3.5x the baseline.If the benchmark was modified to set an heap value rather than an immediate the T_OBJECT case would be much closer to the other two: