YJIT: Lazily enable YJIT after prelude

[k0kubun]

Currently, YJIT compiles code for prelude as well. But some code used by prelude may not be used ever again after prelude, which could bring less localized code and unnecessary pressure on code GC.

JITing prelude seems just useless if it doesn't contribute to speeding up prelude. And the cost of JITing prelude seems to outweigh the JITed code's speedup. So I'd like to propose not JITing prelude.

Before

$ time ruby -v --yjit -e ''
ruby 3.2.0dev (2022-10-20T00:45:36Z master 2e3b764ad1) +YJIT [arm64-darwin21]
ruby -v --yjit -e ''  0.05s user 0.02s system 91% cpu 0.071 total

After

$ time ruby -v --yjit -e ''
ruby 3.2.0dev (2022-10-20T00:45:54Z yjit-lazy-init f60a1b4ce3) +YJIT [arm64-darwin21]
ruby -v --yjit -e ''  0.04s user 0.01s system 90% cpu 0.058 total

I've tried both multiple times, and this PR was reliably faster.

[noahgibbs]

This looks like a good idea to me.

[maximecb]

Just to make sure I understand, this enables YJIT after Ruby is done loading Ruby runtime code? Is that what you mean by prelude?

[noahgibbs]

The prelude is the pre-loaded things like Rubygems which are loaded before the "real start" of the Ruby code in the file you specify (or equivalent -e param(s) to eval). So this won't affect e.g. Rails initialisers, they happen long after the prelude. But it will keep us from starting to JIT Rubygems' startup code, which seems like a good idea to me.

It would probably be an even better idea to have some way to not start JITting until an app-specified location, e.g. after Rails startup. But that would need more of an API. This has the advantage that it's really clear where to start.