-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Fix object_id
for classes and modules in namespace context
#13315
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
Conversation
This comment has been minimized.
This comment has been minimized.
d0e8149
to
062ea1c
Compare
@byroot When the As far as I understood, the root cause of this problem in the current implementation is
My original idea (popped up in talking w/ @ko1 ) to solve this problem is, when the |
That's another possibility indeed. Just seem more work than this PR, and this PR has the advantage of getting rid of a known Ractor contention point at the same time. |
From my viewpoint:
|
Well, technically these bytes are currently wasted, so the size in unchanged. And you solution would mean one more |
This patch looks really nice to me. |
Ah, probably I misunderstand something. |
No, you were right, I'm the one that was wrong, this indeed make classes one |
@byroot The simplicity is important, I think. So Let's merge this change, and let's rethink later when we need to reduce a |
Yes, I'd rather get a fix out, because right now |
1e64121
to
054dba1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. One place I think TSan will complain, but I'm not sure it's worth caring about.
gc.c
Outdated
static VALUE | ||
class_object_id(VALUE klass) | ||
{ | ||
VALUE id = RCLASS(klass)->object_id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to do an atomic load here, otherwise TSan will complain, but I think in practice it doesn't matter here (ie. an atomic load with memory order relaxed should work). So not a blocker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I had to implement RUBY_ATOMIC_VALUE_LOAD
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I couldn't make it work, so I used the same hack you used in string.c
. Sorry.
object_id
for classes in modules in namespace contextobject_id
for classes and modules in namespace context
74fc4ed
to
ee3bcd0
Compare
How about adding |
ee3bcd0
to
710a18c
Compare
I don't think it adds a lot of value because the |
710a18c
to
b7022f2
Compare
Given classes and modules have a different set of fields in every namespace, we can't store the object_id in fields for them. Given that some space was freed in `RClass` we can store it there instead.
b7022f2
to
e53c2ea
Compare
Given classes and modules have a different set of fields in every namespace, we can't store the
object_id
in fields for them.First because the
shape_id
is different if an object has anobject_id
, so we'd lookup the ID in ast_table
that may not have it and crash.But even if somehow each
class_ext
had ashape_id
, theobject_id
would be different in every namespace, and as far as I understand that's not how namespaces are supposed to work.Given that some space was freed in
RClass
we can store it there instead, which has the benefit of allowing it to be lockless (not fully in this PR but I have another one to generate object IDs atomically).@tagomoris did I get namespaces correctly?
Also cc @jhawthorn