Object#hash: use the object address for T_OBJECT #13765
Conversation
| * | ||
| * @internal | ||
| */ | ||
| RUBY_FL_ADDRESS_SEEN = (1<<6), |
There was a problem hiding this comment.
If only T_OBJECT can use this strategy, we can use a FL_USER flag instead of a global flag.
This comment has been minimized.
This comment has been minimized.
| #else | ||
| #error "Unexpected VALUE size" | ||
| #endif | ||
| rb_obj_field_set(obj, rb_shape_transition_old_address(shape_id), 0, old_address); |
There was a problem hiding this comment.
Actually this doesn't work well. rb_shape_transition_old_address will lookup or insert into a managed_id_table which may be a T_MOVED.
So it's currently not possible to make any shape transition (other than shape_id flags) as part of compaction.
There was a problem hiding this comment.
Another reason it doesn't work, is that if the shape currently has a single child, creating a second child need to allocate a managed_id_table.
So for this whole PR to work, the compaction rb_gc_update_moved_object would need to be invoked once it's now OK to allocate objects (or the transition being created before allocations are disallowed).
Rather than to generate an object_id, we can use the object address. However we have to record that we did, so that if the object is later moved, we know to record its original address inline, so that it keeps a stable hash. We can't use the same strategy for other objects because they delegate their fields to another IMEMO/fields object. So if they don't yet have fields or if the fields object is full, during compaction we'd need to allocate another one but that not allowed during GC.
casperisfine
force-pushed
the
address-in-shape-2
branch
from
0c6a801 to
b40b0ba
Compare
Updated attempt at: #13290
Rather than to generate an object_id, we can use the object address. However we have to record that we did, so that if the object is later moved, we know to record its original address inline, so that it keeps a stable hash.
We can't use the same strategy for other objects because they delegate their fields to another IMEMO/fields object. So if they don't yet have fields or if the fields object is full, during compaction we'd need to allocate another one but that not allowed during GC.