Skip to content

Move object_id in attributes #13159

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 of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

casperisfine
Copy link
Contributor

And get rid of the obj_to_id_tbl

It's no longer needed, the object_id is now stored inline
in the object.

We still need the inverse table in case _id2ref is invoked, but
we lazily build it by walking the heap if that happens.

This comment has been minimized.

@casperisfine casperisfine force-pushed the object_id-in-shape branch 3 times, most recently from 1aae814 to d8c231b Compare April 24, 2025 09:31
}

if (rb_shape_has_object_id(shape)) {
// We could avoid locking if the object isn't shareable
Copy link
Contributor Author

Choose a reason for hiding this comment

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

For T_MODULE and T_CLASS it might be worth finding 8B in rb_classext_t so we can do some atomic CAS and find_or_create the object_id with no actual locking.

But if we need to also set the FL_SEEN_OBJ_ID flag, it might be more tricky than that?

@casperisfine casperisfine force-pushed the object_id-in-shape branch 3 times, most recently from f1b501e to 63e2d8d Compare April 25, 2025 11:56
gc.c Outdated
void
rb_gc_obj_free_vm_weak_references(VALUE obj)
{
if (FL_TEST_RAW(obj, FL_SEEN_OBJ_ID)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

FL_SEEN_OBJ_ID isn't very useful anymore, except for SHAPE_TOO_COMPLEX, but we could improve that too.

If we always check the shape flags, we could reclaim that flag.

Also more broadly, shape_id_t is 32bit on 64bit systems, which is way more than we need. If needing to lookup the shape to know if it has an object_id (or is frozen) we could actually pack these tags in the most significant bits of the shape_id.

@casperisfine casperisfine force-pushed the object_id-in-shape branch 2 times, most recently from d4219f3 to 69b378b Compare April 30, 2025 06:53
byroot and others added 18 commits April 30, 2025 17:13
This opens the door to store more informations in shapes, such
as the `object_id` or object address in case it has been observed
and the object has to be moved.
And get rid of the `obj_to_id_tbl`

It's no longer needed, the `object_id` is now stored inline
in the object.

We still need the inverse table in case `_id2ref` is invoked, but
we lazily build it by walking the heap if that happens.
We can't do unsychronized reads for shareable objects, which
include all modules and classes.
Since we assume most programs don't ever build the id2obj table,
we can just implement it as a simple TypedData object.
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
Co-Authored-By: Matt Valentine-House <matt@eightbitraptor.com>
Ivars no longer are the only thing stored inline
via shapes, so keeping `iv_index` would be confusing.
Right now everything assume only one shape is too_complex.
e.g. `shape_id == OBJ_TOO_COMPLEX_SHAPE_ID`.

In the near future I'd like to have more than one complex
shape, e.g. `frozen & too_complex`, `have_id & too_complex`.
You still cannot transition from TOO_COMPLEX into an IVAR
shape, however you now can transitiont o FROZEN or OBJ_ID.

This allows to store in the shape that we're froen or have an object_id,
allowing to free object flags.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants