[ruby-core:121114] [Ruby master Feature#21140] Add a method to get the address of certain JIT related functions
From:
"Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date:
2025-02-18 22:17:17 UTC
List:
ruby-core #121114
Issue #21140 has been updated by Eregon (Benoit Daloze). tenderlovemaking (Aaron Patterson) wrote in #note-14: > I don't think providing the method _hurts_ anything. It's experimental and unstable, so people who build anything with it should understand the risks of depending on it. I used to be of that opinion but clearly time has shown that people or gems have abused RubyVM too much already. A prime example of that is quite a few gems depend or depended on RubyVM::AbstractSyntaxTree, even though it was marked as experimental/unstable/etc (e.g the order of node children could change incompatibly at any time, and no way to access by name). >>From my POV it took several years of work on Prism, making it the official API for parsing Ruby, and then migrating those gems to Prism to clean that mess. I think RubyVM::AbstractSyntaxTree should have never been available by default, it should have been behind a configure flag or so, as a debug/research tool (or only as text output, like `--dump=parsetree`). A runtime flag might have been enough (I'm not sure, it feels more risky) to discourage using it for anything but experiments. Similar for RubyVM::InstructionSequence, it would be possible to design an API which is not tight to CRuby bytecode but can support serializing & deserializing a binary form of source code. But because RubyVM::InstructionSequence exists it will probably never be attempted. Things like getting the start/end column and end line got delayed by years because there were workarounds with `RubyVM`, which other Ruby implementations must not implement to not break more code. I can see how this request is not really of the same scope, but it is asking to expose deep internals of the VM like non-exported (`static`) functions. Those are likely to change so it feels wrong to expose them in any way. When RJIT was part of core it was more OK to use such internals as it could be evolved with CRuby, but that's no longer the case so it should use more stable APIs/rely less on internals. How about reviewing the functions RJIT really needs, and those it could work around? And then maybe having the ones really needed as exported functions (e.g. without declaration in header to make it not too easy) or static inline (in a separate header to make it clear it's not part of the Ruby C API). BTW for `static inline` functions those can easily be accessed with a C extension, e.g. `rb_ary_entry_internal()` in https://github.com/ruby/ruby/blob/27ba268b75bbe461460b31426e377b42d4935f70/internal/array.h#L54-L68. ---------------------------------------- Feature #21140: Add a method to get the address of certain JIT related functions https://bugs.ruby-lang.org/issues/21140#change-112036 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Feature #21116 extracted RJIT as a gem. But RJIT accesses certain internal functions which it cannot access as a gem. For example it used the `rb_str_bytesize` function, but this symbol is not exported, so we cannot access it (even from a C extension). Instead of exporting these symbols, I would like to propose an API for getting access to their addresses in Ruby. For example ```ruby RubyVM::RJIT.address_of(:rb_str_bytesize) # => 123456 ``` I would like to limit the addresses to [this list](https://github.com/ruby/ruby/blob/f32d5071b7b01f258eb45cf533496d82d5c0f6a1/tool/rjit/bindgen.rb#L510-L578) which are the ones required by RJIT. -- 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/