ZJIT: Precise GC writebarriers #13935
Conversation
This issues writebarriers for objects added via gc_offsets or by profiling. This may be slower than writebarrier_remember, but we would like it to be more debuggable. Co-authored-by: Max Bernstein <ruby@bernsteinbear.com> Co-authored-by: Stan Lo <stan001212@gmail.com>
There was a problem hiding this comment.
Sounds good to me.
Side note: we should really have a proper object pool instead of baking VALUEs directly into code. It's one of those things that we never got around to doing for YJIT. Should be faster to mark an array of VALUEs than to scavenge VALUEs everywhere in generated code.
|
looks good to me too.
seems fair.
About the object pool idea, I'm still worried about a potential overhead added by introducing one indirection that doesn't exist today. If production gets better CoW efficiency, it'd be a fair trade-off in terms of overall performance, but I'd like us to carefully evaluate the speed when we get to work on it. |
Sorry, the latter half of my comment might have confused you, but it has nothing to do with this PR. You don't need to disable auto-merge 😅 I'll issue one again. |
|
Haha, no, unrelated to your comment -- I got excited and forgot about how we have been normally letting committers merge on their own post-review and non-committers expressly request a merge |
|
ok, I'll disable mine too then |
This issues writebarriers for objects added via gc_offsets or by profiling. This may be slower than writebarrier_remember, but we would like it to be more debuggable.
We found the lack of gc_offset writebarriers via wbcheck