Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here.
Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation.
So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.
Earnestly: why are you annoyed? I tried to make it clear that you don't have to make any changes. If you want, you can try ZJIT (which should not be anything other than a one character change), but you don't have to.
Because now YJIT is deprecated and at some point in a year or two I will have to have my team go through and switch everything from YJIT to ZJIT. So it's creating random tech debt busywork that will suck up dev resources that could better be used building features.
In isolation, having to switch from YJIT to ZJIT isn't that bad, but this same type of churn happens across so much of the frameworks and technologies that my company uses that in aggregate it becomes quite an annoyance.
I assume you upgrade your Ruby VM? You also upgrade to use YJIT? And you will upgrade to ZJIT?
Not only do you get them for free, you get performance improvement for free. And YJIT is still supported and not depreciated. Not only is Ruby on Rails dont have churn anywhere near the order of magnitude of JS world. It is perhaps one of the stablest and non-moving framework and languages, to the point it is moving slowly and boring compared to even modern PHP and Python.
I dont even work on YJIT or ZJIT but I find this entitlement on OSS, even when you are getting newer upgrade and improvement for free, for all the benefits it provides while having so little downside being called "random tech debt busywork" frankly very rude.
In this case, we used to abort (i.e. abort(); intentionally crash the entire process) but now we jump into the interpreter to handle the dynamic behavior.
If someone writes dynamic ruby code to add two objects, it should succeed in both integer and string cases. The JIT just wants to optimize whatever the common case is.
I’m assuming that when you talk about crashing processes as the status quo you’re referring to earlier versions of zjit rather than current Ruby on yjit? Because I’ve never seen a Ruby process crash because + was called with different arguments.
I guess I’m confused why an actual add instruction is emitted rather than whatever overloaded operation takes place when the + symbol (or overloaded add vtable entry) is called (like it would in other OOP languages).
If all you're doing is summing small integers---frequently the case---it's much preferable to optimize that to be fast and then skip the very dynamic method lookup (the slower, less common case)
reply