GC: Account for variable width allocs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Shopify upstreamed an important change to MRI: the ability for the GC to allocate heap slots larger than 40B (RVALUE_SIZE): https://shopify.engineering/ruby-variable-width-allocation

This reduces the necessity to malloc additional heap space to store large objects. However, it also means that some optimizations modern malloc implementation like jemalloc perform such as filing objects into different size buckets to minimize fragmentation are lost.

MRI pre-allocates a fixed number of heap slots on VM boot, but it is not easily specified how many slots of which size it should pre-allocate. As described in https://shopify.engineering/adventures-in-garbage-collection, this can now also be specified through an environment variable.

We should:

  • Revisit GC stats with the 3.2 upgrade and understand how our objects distribute in size
  • Make sure memory instrumentation is still correct since it currently assumes a fixed RValue width
  • If necessary, tweak RUBY_GC_HEAP_INIT_SIZE_%d_SLOTS accordingly to warm up GC
  • Consider tracking GC.stat_heap metrics in RubySampler

Links:

Edited by 🤖 GitLab Bot 🤖