Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add shape_id to RBasic under 32 bit #13341

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 5 commits into
base: master
Choose a base branch
from

Conversation

jhawthorn
Copy link
Member

@jhawthorn jhawthorn commented May 14, 2025

[Feature #21353]

This adds a separate VALUE-sized shape_id field for 32-bit platforms. Allowing them to work much more similarly to how shapes always being available on 64-bit.

This does increase the size of objects by 4 bytes on 32 bit platforms, but shape access should be faster, more consistent, of the same size (32 bits) and much simpler.

This comment has been minimized.

@jhawthorn jhawthorn force-pushed the shape_id_in_flags_32 branch from 96f185e to 9755585 Compare May 15, 2025 17:19
@jhawthorn jhawthorn changed the title WIP: Add shape_id to RBasic under 32 bit Add shape_id to RBasic under 32 bit May 17, 2025
@jhawthorn jhawthorn marked this pull request as ready for review May 17, 2025 01:35
#if RBASIC_SHAPE_ID_FIELD
RBASIC(obj)->shape_id = 0;
#endif
}
Copy link
Member

Choose a reason for hiding this comment

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

Since this is added, how about adding RBASIC_FLAGS & RBASIC_SET_FLAGS as in oracle/truffleruby#3118 (comment) ?
That would help reduce the amount of direct accesses to that field, and could add extra asserts (e.g. catching some code trying to set the frozen flag directly), etc.

Should RBASIC_SET_FLAGS(obj, 0) reset the shape too?

@@ -153,4 +166,13 @@ RBASIC_CLASS(VALUE obj)
return RBASIC(obj)->klass;
}

static inline void
RBASIC_RESET_FLAGS(VALUE obj)
Copy link
Member

Choose a reason for hiding this comment

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

Should this be in public headers (it is in the current state of this PR) or under internal/**/*.h?
IOW, do you think any C extension would need this, or just CRuby .c files?

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