Also, what's the long-term plan for YJIT.
One thing that's struck me with the new code is that's its so easy to follow compared to rails. It's like two different extremes on the implicit-explicit spectrum. Yet it's not like I have tons more boilerplate code now, I think I have maybe 10 or 20% more SLOC than before.
I'll probably do this with my other rails apps as well.
ComputerGuru•31m ago
> This meant that the code we were running had to continue to have the same preconditions (expected types, no method redefinitions, etc) or the JIT would safely abort. Now, we can side-exit and use this feature liberally.
> For example, we gracefully handle the phase transition from integer to string; a guard instruction fails and transfers control to the interpreter.
> (example showing add of two strings omitted)
What is the difference between the JIT safely aborting and the JIT returning control to the interpreter? Or does the JIT abort mean the entire app aborts (i.e. I presumed JIT aborting means continuing on the interpreter anyway?)
(Also, why would you want the code that uses the incorrect types to succeed? Isn’t abort of the whole unit of execution the right answer here, anyway?)
nt591•19m ago
An example might be the plus operator. Many languages will allow integers, floats, strings and more on either side of the operator. The JIT likely will see mostly integers and optimize the functions call for integer math. If later you call the plus operator with two Point classes, then you would fall back to the interpreter.
tekknolagi•6m ago
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.