This is a new Garbage collector built using the new GC API introduced in
https://bugs.ruby-lang.org/issues/20470

It's modelled on the Epsilon collector introduced in JDK 11. A No-Op
collector that implements memory allocation but no memory reclamation.
Memory will continue to be allocated until the process exhausts all
available memory and is shut down by the OS's OOM killer.

This GC has the lowest possible GC latency, at the expense of memory
footprint and throughput.

This is primarily useful for experimentation and testing, and provides a
"second system" in order to continue testing the GC API.

This collector uses the same heap/page/slot allocation strategy as
Ruby's existing GC. This was done for a few reasons:

- Memory throughput: Traditionally and Epsilon collector would malloc
  every allocation, this GC uses an already established Ruby allocation
  implementation to reduce the number of malloc/free calls during
  allocation, allowing allocation to be faster.
- Familiarity: Developers of the Ruby GC are already familiar with how
  allocation works in Ruby, this GC should remain simple to work on.
- Simplicity: Using the existing allocation strategy allowed us to
  develop this quickly, and avoid having to deal with alignment issues,
  or abstraction leakage issues over the API.

The epsilon collection can be built as a shared library as follows:

Mac:

clang -I../src/include -I. -I../src -I.ext/include/arm64-darwin23 -Wall -undefined dynamic_lookup -g -O0 -dynamiclib -o gc/epsilon.dylib ../src/gc/epsilon.c

Linux:

gcc -O0 -g -I. -I../src/  -I../src/include -I./.ext/include/x86_64-linux/ -Wall -fPIC -shared -lc ../src/gc/epsilon.c -o gc/epsilon.so

Ruby must be built with shared GC support, and the correct library
directory set in the configure path.

./configure --with-shared-gc=$(pwd)/gc

Then, the EpsilonGC can be loaded at runtime using the RUBY_GC_LIBRARY
environment variable

RUBY_GC_LIBRARY=epsilon.dylib ./ruby test.rb

[Feature #20612]

[Feature #20612]

[Feature #20612]