8000 Refactor generic fields to use `T_IMEMO/fields` objects. by casperisfine · Pull Request #13626 · ruby/ruby · GitHub
[go: up one dir, main page]

Skip to content

Refactor generic fields to use T_IMEMO/fields objects. #13626

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms 8000 of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 17, 2025

Conversation

casperisfine
Copy link
Contributor

Followup: #13589

This simplify a lot of things, as we no longer need to manually manage the memory, we can use the Read-Copy-Update pattern and avoid numerous race conditions.

@matzbot matzbot requested a review from a team June 16, 2025 14:17

This comment has been minimized.

Copy link
Member
@tenderlove tenderlove left a comment

Choose a reason for hiding this comment

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

What is the difference between generic_field_set and generic_ivar_set? It seems like "fields" is just used for object ids?

I see some logic WRT shapes in generic_update_fields_obj, but I don't know if that's legit for both code paths. Other than that, I can't see from this diff what the problem is.

MEMCPY(fields, rb_imemo_fields_ptr(original_fields_obj), VALUE, fields_count);
for (attr_index_t i = 0; i < fields_count; i++) {
RB_OBJ_WRITTEN(fields_obj, Qundef, fields[i]);
}
Copy link
Member

Choose a reason for hiding this comment

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

I think we could do rb_gc_writebarrier_remember(fields_obj) here so we don't have to iterate the list. Someone will eventually have to iterate this list, but at least we only need to put 1 item in the remembered set instead of N items.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm unfamiliar with rb_gc_writebarrier_remember but I'll read on it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hum, I tried to use it as a replacement for firing write barriers on all fields, but instantly ran into GC crashes. So I suspect I don't understand how it's meant to be used.


fields_lookup->resize = true;
}
generic_update_fields_obj(obj, fields_obj, original_fields_obj);
Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a comment here that generic_update_fields_obj fires a WB? I was looking for missing WBs. This function clearly fires them from the fields object to the values, but I couldn't see where the obj -> fields_obj barrier is fired.

@casperisfine
Copy link
Contributor Author

What is the difference between generic_field_set and generic_ivar_set? It seems like "fields" is just used for object ids?

Yes, currently it's only used for object_id, eventually it would be used for "old_address" too #13290

Ideally I'd like ivar_set to just call into field_set, but I need to put more thoughts into it.

@casperisfine casperisfine force-pushed the generic-obj-fields branch 7 times, most recently from db3466b to fa0a255 Compare June 17, 2025 09:48
@casperisfine casperisfine force-pushed the generic-obj-fields branch 3 times, most recently from f7b04e8 to 985ce43 Compare June 17, 2025 11:28
byroot and others added 5 commits June 17, 2025 14:29
Followup: ruby#13589

This simplify a lot of things, as we no longer need to manually
manage the memory, we can use the Read-Copy-Update pattern and
avoid numerous race conditions.

Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
@casperisfine casperisfine force-pushed the generic-obj-fields branch 2 times, most recently from a13de46 to 23a70aa Compare June 17, 2025 12:42
@byroot byroot merged commit 8faa323 into ruby:master Jun 17, 2025
87 of 88 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.

3 participants
0