Ractor: Fix moving embedded objects #13008
Merged
+157
−104
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d7a36b4 to
092b115
Compare
This comment has been minimized.
This comment has been minimized.
3b86dfb to
cb3fc8f
Compare
cb3fc8f to
c7b05f0
Compare
casperisfine
commented
Mar 30, 2025
gc.c
Outdated
Comment on lines
2668
to
2670
| if (UNLIKELY(FL_TEST_RAW(src, FL_SEEN_OBJ_ID))) { | ||
| rb_gc_impl_object_id_move(objspace, dest, src); | ||
| } |
There was a problem hiding this comment.
I suppose the big argument for not transferring the object_id is that we'd save on locking the VM.
There was a problem hiding this comment.
I don't think ID should be inherited (moved object should be different object).
There was a problem hiding this comment.
I did it because to me it seemed that semantically, move: true means we're just changing which ractor owns the object, and not allocating a new object.
But if you think it shouldn't be preserved, it's fine by me, I don't think it's very importan.
Removed.
[Bug #20271]
[Bug #20267]
[Bug #20255]
`rb_obj_alloc(RBASIC_CLASS(obj))` will always allocate from the basic
40B pool, so if `obj` is larger than `40B`, we'll create a corrupted
object when we later copy the shape_id.
Instead we can use the same logic than ractor copy, which is
to use `rb_obj_clone`, and later ask the GC to free the original
object.
We then must turn it into a `T_OBJECT`, because otherwise
just changing its class to `RactorMoved` leaves a lot of
ways to keep using the object, e.g.:
```
a = [1, 2, 3]
Ractor.new{}.send(a, move: true)
[].concat(a) # Should raise, but wasn't.
```
If it turns out that `rb_obj_clone` isn't performant enough
for some uses, we can always have carefully crafted specialized
paths for the types that would benefit from it.
That seemed like the logical thing to do to me, but ko1 disagree.
c7b05f0 to
902e298
Compare
eileencodes
added a commit
to eileencodes/ruby
that referenced
this pull request
Apr 2, 2025
In ruby#13008 `RVALUE` was removed without replacement. This means the lldb scripts that relied on `RVALUE` stopped working. I updated the ones that were using it just for the bytesize to use `slot_size` and then round to the nearest power of 40. We can't use `slot_size` directly because in debug mode it's `48` but `RVALUE` is `40` bytes. For the `as_type` method, I updated it to check the type. It's only used for `bignum` and `array` so that's a simple change. Lastly, for the `dump_page` method I replaced it with `struct free_slot` since that's looking at the freelist. `struct RVALUE` has been removed from all the scripts and I verified that `rp` is fixed. I'm not confident the `dump_page` method is fixed, the freelist looks off, but for now this gets us closer.
eileencodes
added a commit
to eileencodes/ruby
that referenced
this pull request
Apr 8, 2025
In ruby#13008 `RVALUE` was removed without replacement. This means the lldb scripts that relied on `RVALUE` stopped working. I updated the ones that were using it just for the bytesize to use `slot_size` and then round to the nearest power of 40. We can't use `slot_size` directly because in debug mode it's `48` but `RVALUE` is `40` bytes. For the `as_type` method, I updated it to check the type. It's only used for `bignum` and `array` so that's a simple change. Lastly, for the `dump_page` method I replaced it with `struct free_slot` since that's looking at the freelist. `struct RVALUE` has been removed from all the scripts and I verified that `rp` is fixed. I'm not confident the `dump_page` method is fixed, the freelist looks off, but for now this gets us closer.
eileencodes
added a commit
that referenced
this pull request
Apr 8, 2025
In #13008 `RVALUE` was removed without replacement. This means the lldb scripts that relied on `RVALUE` stopped working. I updated the ones that were using it just for the bytesize to use `slot_size` and then round to the nearest power of 40. We can't use `slot_size` directly because in debug mode it's `48` but `RVALUE` is `40` bytes. For the `as_type` method, I updated it to check the type. It's only used for `bignum` and `array` so that's a simple change. Lastly, for the `dump_page` method I replaced it with `struct free_slot` since that's looking at the freelist. `struct RVALUE` has been removed from all the scripts and I verified that `rp` is fixed. I'm not confident the `dump_page` method is fixed, the freelist looks off, but for now this gets us closer.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
[Bug #20271]
[Bug #20267]
[Bug #20255]
rb_obj_alloc(RBASIC_CLASS(obj))will always allocate from the basic 40B pool, so ifobjis larger than40B, we'll create a corrupted object when we later copy the shape_id.Instead we can use the same logic than ractor copy, which is to use
rb_obj_clone, and later ask the GC to free the original object.We then must turn it into a
T_OBJECT, because otherwise just changing its class toRactorMovedleaves a lot of ways to keep using the object, e.g.:If it turns out that
rb_obj_cloneisn't performant enough for some uses, we can always have carefully crafted specialized paths for the types that would benefit from it.