Hacker News Reader

Comment by Lerc | Hacker News Reader

I was a bit surprised by

>When a method has been called a certain number of times (10,000 times in current prerelease Ruby 2.7), MJIT will mark it to be compiled into native code and put it on a “to compile” queue. MJIT’s background thread will pull methods from the queue and compile them one at a time into native code.

I would have thought that you wouldn't wait for 10,000 iterations but just start from the beginning and compile the methods with the most calls and keep the compiler thread busy. Flush less frequently or no-longer needed compiled calls and limit the total to some defined resource usage cap. You'd probably win overall.

View on HN

For what it's worth, the JVM defaults to 10,000 times for a method being called before deciding it is hot, so that threshold is not without precedent (but can be adjusted via XX:CompileThreshold)

Interesting. In .NET Core 2.1, they decided just 30 calls was enough to recompile from the fast “tier 0” JIT code to the fully optimized “tier 1” JITed code.

https://github.com/dotnet/coreclr/blob/master/Documentation/...

It also uses a heuristic to check if application startup has finished to decide whether a call counts towards the tier1 JIT threshold.

10,000 calls really isn't that many, when you consider the sorts of operating environments that the JVM is targetted at.

30 seems crazy low to me. That seems like you'd be spending a bunch of compute time early on compiling stuff that may be only used during the start-up stages of your code.

> I would have thought that you wouldn't wait for 10,000 iterations

I haven't kept up with Ruby JITs, so I don't know if / how mjit handles inlining, but what I remember from my J9 / OMR days is that choosing what to inline made a massive difference in compiled code performance. Inlining too much was a great way to hobble performance.

> Flush less frequently or no-longer needed compiled calls...

The technical complexity of this process should not be underestimated. Given the minimalism of mjit's approach, I could easily see such a strategy being unviable without infrastructure investment that would (at least appear to) be significantly further along the effort / reward curve.

Earlier 2.6 versions of Ruby used 5 as the threshold. For a variety of reasons, that was way too low.

Reply on news.ycombinator.com