Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

Non-ruby dev here. Can someone explain the side exit thing for me?

> 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?)

View on HN

Dynamic languages will allow a range of types through functions. JITs add tracing and attempt to specialize the functions based on the observed types at runtime. It is possible that later on, the function is called with different types than what the JIT observed and compiled code for. To handle this, JITs will have stubs and guards. You check the observed type at runtime before calling the JITted code. If the type does not match, you would call a stub to generate the correct machine code, or you could just call into the interpreter slow path.

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.

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 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)

Presumably other languages with JIT do exactly the same thing?

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.

Yes; see the first ZJIT blog post. https://railsatscale.com/2025-05-14-merge-zjit/

Reply on news.ycombinator.com