[PATCH] Don't force major GC when there are allocatable slots [Bug #21838] When we have allocatable slots, we can grow the heap instead of forcing a major GC. This prevents major GC to be ran very often in certain situations. See the ticket for more details. On ruby-bench, we can see that this patch doesn't cause any significant regressions: -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 148.2 0.3 59.2 150.0 0.8 69.7 1.015 0.988 chunky-png 435.2 0.3 72.9 438.8 0.1 66.7 0.993 0.992 erubi-rails 733.8 1.2 118.7 704.8 0.2 98.3 1.077 1.041 hexapdf 1400.4 1.1 247.0 1405.0 0.9 223.7 0.986 0.997 liquid-c 32.5 3.3 32.8 32.5 2.1 30.7 1.042 0.999 liquid-compile 31.0 1.7 35.1 33.4 3.9 32.8 0.938 0.928 liquid-render 84.7 0.4 30.8 86.3 0.4 30.8 0.981 0.982 lobsters 594.7 0.6 310.5 596.6 0.4 306.0 1.057 0.997 mail 75.6 2.8 53.3 76.9 0.7 53.2 0.968 0.982 psych-load 1122.8 1.2 29.2 1145.1 0.4 31.7 0.964 0.981 railsbench 1244.7 0.3 115.5 1254.8 1.1 115.2 0.939 0.992 rubocop 103.7 0.5 94.1 104.3 0.5 92.4 0.985 0.994 ruby-lsp 88.3 0.6 78.5 88.5 1.2 77.9 0.992 0.997 sequel 26.9 0.9 33.6 28.3 1.4 32.1 0.954 0.952 shipit 1119.3 1.5 171.4 1075.7 2.1 162.5 1.873 1.040 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- -------------
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.
I believe this was accidentally left in as part of 2beb3798bac52624c3170138f8ef65869f1da6c0
This reverts commit 228d13f6ed914d1e7f6bd2416e3f5be8283be865. This commit makes default.c and mmtk.c depend on shape.h, which prevents them from building independently.
Attempt to fix the following SEGV: ``` ruby(gc_mark) ../src/gc/default/default.c:4429 ruby(gc_mark_children+0x45) [0x560b380bf8b5] ../src/gc/default/default.c:4625 ruby(gc_mark_stacked_objects) ../src/gc/default/default.c:4647 ruby(gc_mark_stacked_objects_all) ../src/gc/default/default.c:4685 ruby(gc_marks_rest) ../src/gc/default/default.c:5707 ruby(gc_marks+0x4e7) [0x560b380c41c1] ../src/gc/default/default.c:5821 ruby(gc_start) ../src/gc/default/default.c:6502 ruby(heap_prepare+0xa4) [0x560b380c4efc] ../src/gc/default/default.c:2074 ruby(heap_next_free_page) ../src/gc/default/default.c:2289 ruby(newobj_cache_miss) ../src/gc/default/default.c:2396 ruby(RB_SPECIAL_CONST_P+0x0) [0x560b380c5df4] ../src/gc/default/default.c:2420 ruby(RB_BUILTIN_TYPE) ../src/include/ruby/internal/value_type.h:184 ruby(newobj_init) ../src/gc/default/default.c:2136 ruby(rb_gc_impl_new_obj) ../src/gc/default/default.c:2500 ruby(newobj_of) ../src/gc.c:996 ruby(rb_imemo_new+0x37) [0x560b380d8bed] ../src/imemo.c:46 ruby(imemo_fields_new) ../src/imemo.c:105 ruby(rb_imemo_fields_new) ../src/imemo.c:120 ``` I have no reproduction, but my understanding based on the backtrace and error is that GC is triggered inside `newobj_init` causing the new object to be marked while in a incomplete state. I believe the fix is to pass the `shape_id` down to `newobj_init` so it can be set before the GC has a chance to trigger.
This should be less common than than many of the other flags, so should not inflate the heap too much. This is desirable because reducing the number of remembered objects will improve minor GC speeds.