094418a6de (master): gc.h: Reintroduce immediate guard in `rb_obj_written`
1 view
Skip to first unread message
Jean Boussier
Dec 16, 2025, 3:00:59 PM (11 hours ago) Dec 16
to ruby...@g.ruby-lang.org
Jean Boussier 2025-12-14 08:50:21 +0000 (Sun, 14 Dec 2025)
New Revision: 094418a6de
https://github.com/ruby/ruby/commit/094418a6de
Log:
gc.h: Reintroduce immediate guard in `rb_obj_written`
This guard was removed in https://github.com/ruby/ruby/pull/13497
on the justification that some GC may need to be notified even for
immediate.
But the two currently available GCs don't, and there are plenty
of assumtions GCs don't everywhere, notably in YJIT and ZJIT.
This optimization is also not so micro (but not huge either).
I routinely see 1-2% wasted there on micro-benchmarks.
So perhaps if in the future we actually need this, it might make
sense to introduce a way for GCs to declare that as an option,
but in the meantime it's extra overhead with little gain.
Modified files:
gc/default/default.c
include/ruby/internal/abi.h
include/ruby/internal/gc.h
New Revision: 094418a6de
https://github.com/ruby/ruby/commit/094418a6de
Log:
gc.h: Reintroduce immediate guard in `rb_obj_written`
This guard was removed in https://github.com/ruby/ruby/pull/13497
on the justification that some GC may need to be notified even for
immediate.
But the two currently available GCs don't, and there are plenty
of assumtions GCs don't everywhere, notably in YJIT and ZJIT.
This optimization is also not so micro (but not huge either).
I routinely see 1-2% wasted there on micro-benchmarks.
So perhaps if in the future we actually need this, it might make
sense to introduce a way for GCs to declare that as an option,
but in the meantime it's extra overhead with little gain.
Modified files:
gc/default/default.c
include/ruby/internal/abi.h
include/ruby/internal/gc.h
Reply all
Reply to author
Forward
0 new messages