Feature #20794
openExpose information about the currently running GC module
Description
Summary¶
Currently it's not possible for the user to easily find out information about the currently running GC, and whether modular GC has been enabled.
The linked PR provides a method for the user to query whether modular GC's are enabled, and whether one is active, as well as a Ruby method that exposes the currently active GC.
Background¶
Since Modular GC was introduced it's been possible to build Ruby with several different GC configurations:
- Modular GC disabled. Existing GC is linked statically, and active - This is the default case
- Modular GC enabled, but not loaded. Existing GC is linked statically and is active.
- Modular GC enabled, and a GC implementation is loaded and overrides the static default GC.
Currently there's not an accurate way of determining which of these states the current Ruby process is in.
This makes writing tests that work accurately given different GC configurations complex. It also means that developers and admins running Ruby aren't able to get accurate information about their Ruby processes.
Proposal¶
This ticket proposes the following changes:
- Add GC status to
RUBY_DESCRIPTION
so it's visible in the output ofruby -v
- Add a method
GC.active_gc_name
that will return the name of the currently running GC as a String.
Implementation¶
The linked PR implements these proposals.
No shared GC support¶
This is the default case. Ruby statically links and uses the existing GC, with no means to override it.
RUBY_DESCRIPTION
is obviously unchanged
❯ ruby -v
ruby 3.4.0dev (2024-10-09T14:20:46Z mvh-active-gc-name 3cb4bd4d43) +PRISM [arm64-darwin24]
and GC.active_gc_name
returns nil
❯ ./ruby -e "p GC.active_gc_name"
nil
Shared GC support enabled, Not loaded¶
This is the case when Ruby has been configured with --with-shared-gc=/path/to/gc
but no GC has been explicitly loaded using the RUBY_GC_LIBRARY
environment
RUBY_DESCRIPTION
will contain +MOD_GC
to indicate that shared GC support is built in. This is similar to how +PRISM
, and +YJIT
work.
❯ ruby -v
ruby 3.4.0dev (2024-10-09T14:38:38Z mvh-active-gc-name 3cb4bd4d43) +PRISM +MOD_GC [arm64-darwin24]
and GC.active_gc_name
still returns nil
. This is because the existing statically linked GC is in use, and has not been overridden.
❯ ./ruby -e "p GC.active_gc_name"
nil
Shared GC support enabled, and modular GC loaded¶
This is the case when Ruby has been configured with --with-shared-gc=/path/to/gc
and an alternative GC library has been explicitly loaded using the RUBY_GC_LIBRARY
environment variable
RUBY_DESCRIPTION
will contain +MOD_GC
to indicate that shared GC support is built in. This is similar to how +PRISM
, and +YJIT
work. In addition it will also contain a GC name, which is a human readable name that each concrete GC implementation needs to provide as part of its API.
This is seen here as +MOD_GC[mmtk]
- because in this case librubygc.dylib
reports it's name as being mmtk
❯ RUBY_GC_LIBRARY=librubygc.dylib ./ruby -v
ruby 3.4.0dev (2024-10-09T14:38:38Z mvh-active-gc-name 3cb4bd4d43) +PRISM +MOD_GC[mmtk] [arm64-darwin24]
GC.active_gc_name
returns the GC's name, as configured by the GC module (this will be identical to the reported name loaded into RUBY_DESCRIPTION
).
❯ RUBY_GC_LIBRARY=librubygc.dylib ./ruby -e "puts GC.active_gc_name"
mmtk
Conclusion¶
This should cover all states that the GC can now be in.
Users can now query the state from the command line to see whether modular GC's are enabled and if so, what GC is active.
From Ruby we can use GC.active_gc_name
in conjunction with the pre-existing option RbConfig::CONFIG['shared_gc_dir']
to find out this same information.
This will now make it easier to run different Ruby processes with different GC builds, as well as make it easier for GC implementors to write tests that behave correctly in all these circumstances.
No data to display