vm.c: restore the GC arena where the Float boxing macro allocates - #7168

VM_SET_INT_VALUE() restores the GC arena at the Integer boxing sites in the interpreter loop, because those opcodes answer inline and have no cfunc epilogue behind them to shrink it. The Float sites box through SET_FLOAT_VALUE(), which under word boxing heap-allocates an RFloat whenever the mrb_value word cannot hold the value inline, and none of them restore. Each iteration of a loop built from those opcodes pins one more object, the mark phase then walks all of them, and the loop is quadratic.

This is not confined to MRB_WORDBOX_NO_INLINE_FLOAT, where every Float is a heap object. Default 64-bit word boxing also sends a subnormal, an exponent outside [-255, +256], and a rotation that would collide with a sentinel to mrb_obj_alloc() (mrb_word_boxing_float_value() in src/etc.c), so an ordinary host build is affected too.

There are five boxing sites:

Four of them sit inside mrb_vm_exec() and take a new VM_SET_FLOAT_VALUE() built to the same shape as the Integer macro: store, then restore unless the store produced an immediate, which is the inline-float fast path and allocates nothing. On a boxing mode that keeps the Float in the word it expands to the bare store.

vm_op_div() is a helper outside mrb_vm_exec(), so neither the macro nor the arena index it restores to is in scope. Rather than thread ai through the signature, it saves its own index around the store and restores to the height on entry to that branch instead of to the height on entry to the frame. That still bounds the arena across a loop, and it is exactly what the Integer branch a few lines above in the same function already does. It is also strictly the more conservative of the two: nothing allocates between entry to vm_op_div() and the save, since the type switch only reads mrb_type(), mrb_integer() and mrb_float() and mrb_div_float() is float arithmetic, so the restore pops exactly the one RFloat the store created and never anything the caller pushed. Either way the result needs no mrb_gc_protect(): it is stored into regs[], and the VM stack is a GC root, which is the same reason the cfunc epilogues can shrink unconditionally.

Measurements

x86-64. Each figure is from a 20000-iteration while loop whose body holds only the opcode under test and i += 1. GC.start is run as the first send after the loop, while the arena still roots what the loop left there, since any cfunc return would drain it first, so the rise in GC.stat[:live] across that collection is the number of pinned objects. The last digit varies by one or two with what happens to be live when the base count is read; only the order of magnitude is meaningful.

Default word boxing, x = 1.0e100:

That is one pinned object per boxing store, and two per iteration for the fused pair. A subnormal (5.0e-324) gives the same figures, except through OP_ADDI and OP_SUBI where a non-zero integer operand normalises the result so nothing is allocated. Under MRB_WORDBOX_NO_INLINE_FLOAT the same figures hold for an ordinary 1.5.

Cost of the retention, while i < n; y = x + z; i += 1; end with x = 1.0e100:

Under MRB_GC_FIXED_ARENA, which the bintest build in build_config/ci/gcc-clang.rb defines, the same loop is not slow but broken. On that build:

$ ./build/bintest/bin/mruby -e 'x = 1.0e100; i = 0; while i < 20000; x + x; i += 1; end; puts "completed"'
trace (most recent call last):
-e:1: NoMemoryError      # before: gc_arena_keep() raises once the arena fills
completed                # after

Tests

The first commit is test-only and rewrites how the existing arena assertions in test/t/gc.rb measure. They read GC.stat[:live] immediately after the loop and compare the rise against a fixed 5000. That does catch a branch that stops restoring altogether, since reverting the OP_GETIDX String restore takes the first assertion from 1 to 20000 and it fails, but the count it reads is the mutator's live set mid-cycle, not what the arena pinned, so a passing run already reports 29 to 806 objects of incremental-sweep lag and the threshold has to clear that. Against the reverted restore, a branch that retained on 4000 of the 20000 iterations reported 4000 and still passed; so did 1000, and 200.

Running the full GC before reading removes the slack entirely: the arena is a GC root, so exactly the pinned objects survive and everything else is swept. The GC.start has to be the first send after the loop, because any cfunc return drains the arena. Every assertion now reports 1 on a restoring tree (OP_SETIDX reports 2), the margin drops from 5000 to 100, and the 4000, 1000 and 200 partial leaks are all reported exactly and all fail. The smallest leak the assertions can miss goes from roughly 22% of the iterations to 0.5%.

The second commit adds four Float assertions in that shape, covering all five sites at both a subnormal and an out-of-range exponent so they bite on a default host build as well as under MRB_WORDBOX_NO_INLINE_FLOAT. With src/vm.c reverted and the tests in place, all four fail:

Fail: OP_MATH does not retain a boxed Float in the GC arena (core)
Fail: OP_DIV does not retain a boxed Float in the GC arena (core)
Fail: OP_ADDI does not retain a boxed Float in the GC arena (core)
Fail: OP_LOADL does not retain a boxed Float in the GC arena (core)

rake -m test on the default host build passes at each of the two commits: mrbtest Total: 2075, KO: 0 after the first and Total: 2079, OK: 2050, KO: 0, Crash: 0, Warning: 0, Skip: 29 after the second, with bintest Total: 105, OK: 105, KO: 0. MRUBY_CONFIG=ci/gcc-clang rake all builds clean, and so does MRUBY_CONFIG=no-float rake all: under MRB_NO_FLOAT the new macro is defined but never expanded, since all five sites sit inside #ifndef MRB_NO_FLOAT.

Summary by CodeRabbit

• Bug Fixes

  • Improved floating-point arithmetic, division, and literal loading across supported boxing configurations.
  • Prevented unnecessary memory retention during repeated floating-point operations.
  • Ensured boxed floating-point results preserve their expected values.

• Tests

  • Expanded garbage-collection coverage for floating-point operations.
  • Added checks for memory growth and correct results across arithmetic scenarios.