We are trying to add the new YJIT feature that is ported to Rust[1][2] in Ruby 3.2 RPM on Fedora project.[3]
I am trying to understand how the YJIT works in the case the ./configure --enable-yjit --enable-shared. In the case below, when building Ruby on the latest master branch 199b59f065ce6f1c13b8424f35a70c513523211b, the static libraries libruby-static.a and ./libruby-static.a were built.
After running make install, these static libraries (*.a files) were not copied to the installed directory. That makes sense, as Ruby works with shared libraries (*.so files).
<mock-chroot> sh-5.2$ make install 2>&1 | tee make_install.log
<mock-chroot> sh-5.2$ find ~/local/ruby-yjit-199b59f065/ -name "*.a"
=> empty
In this case, we really don't need the libyjit.a to run the YJIT right? I couldn't find the .so file something like yjit.so. Which .so file contains the YJIT feature (maybe the content of the yjit/src/**/*.rs)?
How can we test the content of the yjit/src/**/*.rs? For example, if the command below works, I can say that I tested the content of the yjit/src/**/*.rs?
How can we test the content of the yjit/src/**/*.rs? For example, if the command below works, I can say that I tested the content of the yjit/src/**/*.rs?
Here is a bit old commit on the master branch 131c31a9209c61f84d318aa18b61f468f48b8219. It was compiled with ./configure --enable-yjit=dev --enable-shared --prefix=$HOME/local/ruby-yjit-dev-so-131c31a920. Can I say that I executed the content of the yjit/src/**/*.rs?
Sorry for my repeated posting. I uninstalled the rustc to check if the Rust compiler is really used in the YJIT process. And the commands worked without the rust command. Could you tell me why it worked?
... the commands worked without the rust command. Could you tell me why it worked?
I can answer this part of the question.
<mock-chroot> sh-5.2$ which rustc
which: no rustc in (/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin)
<mock-chroot> sh-5.2$ ~/local/ruby-yjit-199b59f065/bin/ruby --yjit --yjit-call-threshold=1 -e '100.times { |n| puts "Hello #{n}" }'
...
Hello 98
Hello 99
YJIT does NOT generate Rust code at runtime to perform its JIT compilation. YJIT is, itself, a Rust code-base that generates the correct assembly code for optimized methods at runtime. So rustc is only needed to compile the YJIT code itself, once you've compiled Ruby with YJIT, there is no dependency on rustc at runtime anymore.
In this case, we really don't need the libyjit.a to run the YJIT right?
Try running make with V=1. You can confirm libyjit.a is linked in the build process (as SOLIBS :p) even with --enable-shared. I don't think YJIT has ever done anything special for --enable-shared; it always builds and uses libyjit.a. libyjit.a doesn't seem to depend on any Rust-related runtime, so removing the rustc package wouldn't impact its behavior. As @ufuk (Ufuk Kayserilioglu) said, it doesn't rely on rustc(1) at runtime either.
YJIT does NOT generate Rust code at runtime to perform its JIT compilation. YJIT is, itself, a Rust code-base that generates the correct assembly code for optimized methods at runtime. So rustc is only needed to compile the YJIT code itself, once you've compiled Ruby with YJIT, there is no dependency on rustc at runtime anymore.
Ah, okay. I misundertood the YJIT behavior. I was thinking that the rustc was executed in the JIT process, that is like the gcc or clang is executed in the MJIT process (#17817).
Try running make with V=1. You can confirm libyjit.a is linked in the build process (as SOLIBS :p) even with --enable-shared. I don't think YJIT has ever done anything special for --enable-shared; it always builds and uses libyjit.a. libyjit.a doesn't seem to depend on any Rust-related runtime, so removing the rustc package wouldn't impact its behavior. As @ufuk (Ufuk Kayserilioglu) (Ufuk Kayserilioglu) said, it doesn't rely on rustc(1) at runtime either.
Thanks for giving the info!
I checked it with the latest master branch 90bbc891b192c30432c517ccb279ed687bb2d0b4 now. And I was able to see the libyjit.a is a part of the SOLIBS in the Makefile, an that the libyjit.a was actually linked to create the libruby.so.3.2.0, miniruby and ruby binary files.
$ ./autogen.sh
$ ./configure --prefix=$HOME/local/ruby-yjit-90bbc891b1 --enable-shared --enable-yjit 2>&1 | tee configure.log
$ make V=1 2>&1 | tee make_v1.log