[toast0]

I don't think the two JITs really do the same work, so it's hard to benchmark them against each other.

Erlang JIT takes BEAM bytecode and turns it into native code once at load time in order to avoid the overhead of the threaded code interpreter; if Erlang JIT is enabled, the interpreter is not used at all. Java's HotSpot JIT takes JVM bytecode and turns it into native code at runtime in order to improve performance of code that is run frequently (thus the name), guided by runtime information; lightly used code will be interpreted, heavily used code will hopefully be JITed to native. When HotSpot JITs, it may apply assumptions based on runtime use to produce faster code and if the assumptions don't hold for a call, the interpreter can be used instead (and if that happens often enough, the native code can be discarded and perhaps rebuilt), so the interpreter needs to be present always.

Erlang JIT has been focused more on always applying and speed of application (because it delays code loading), whereas HotSpot focuses more on getting performance gains when it applies, and speed of application is less important because it happens asynchronously. So if you benchmarked speed of applying the JIT, Erlang would probably win, and if you benchmarked optimization of the code, HotSpot would probably win, but either way you're comparing apples and oranges.