From: "peterzhu2118 (Peter Zhu) via ruby-core" Date: 2025-01-09T17:50:16+00:00 Subject: [ruby-core:120588] [Ruby master Bug#21022] The --with-modular-gc= option is cumbersome Issue #21022 has been updated by peterzhu2118 (Peter Zhu). > What is the intended configuration? We realize that this feature is currently cumbersome to use as it requires a compile time option, an environment variable, and a built GC library. We need the compile time option as there is a performance penalty when modular GC is enabled, as shown in the benchmarks in #20470. This is because the GC is no longer statically compiled and we use function pointers instead, which prevents compiler optimizations. > I'd expect that something like RUBY_GC_LIBRARY=/home/johndoe/path/to/gc/gc.so ruby -e 'puts "Hello custom GC"' would be command to run. That was the original design, however, in [[Feature #20470]](https://bugs.ruby-lang.org/issues/20470#note-1) it was decided that this was a security concern due to the possibility to execute arbitrary code using environment variables. The compromise is to specify a directory at build time using `--with-modular-gc=`, and only accept binaries placed in that directory. > Actually I wonder why the GC is not packaged as gem? Maybe RubyGems are late to the party to load the GC early enough. But they still would be nice method of distribution. That is the the ultimate goal. We will probably need to do modifications to bundler to get this to work. > But from the Ruby 3.4, the Modular GC seems to be as something users might want. The feature is experimental, so we don't enable it for the vast majority of the users who don't want it. ---------------------------------------- Bug #21022: The --with-modular-gc= option is cumbersome https://bugs.ruby-lang.org/issues/21022#change-111413 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM +GC [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Just experimenting a bit with the `--with-modular-gc=` if it is worth of enabling in Fedora, but I somehow cannot wrap my head around that. What is the intended configuration? >From Fedora POV, we have Ruby installed somewhere in `/usr`, which can only be managed by RPM. I don't think that we would like to package any additional GC. But if we wanted, we would likely installed it outside of the default Ruby directory structure. We would also like our users to experiment. So they would ideally have their GC built somewhere in their HOME. In that case, I'd expect that something like `RUBY_GC_LIBRARY=/home/johndoe/path/to/gc/gc.so ruby -e 'puts "Hello custom GC"'` would be command to run. But it does not seems that the current configuration option / env variables have anything like this in their mind. Actually I wonder why the GC is not packaged as gem? Maybe RubyGems are late to the party to load the GC early enough. But they still would be nice method of distribution. >From #20860 I understand that the MMTk is experimental. But from the Ruby 3.4, the Modular GC seems to be as something users might want. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/