[brabel]

If you're writing the interpreters in Java (or other language compiled to JVM bytecode) your code itself is going to be interpreted and JIT'd on the go by the JVM, so it's really difficult to come up with real optimisations to your interpreter.

In my experience, the JVM "likes" dumb code: direct, without abstractions on top. Use static final methods for everything, no inheritance, avoid memory allocation (though the JVM is insanely good at optimising small, short memory usage). In a bytecode interpreter you may be tempted to use "proper" type hierarchies with Ops represented by interfaces and things like that. Instead, using an array of objects of the same type which can hold the "variants" (basically, C-style OOP without vtables) of each Op is what makes things go from slow to fast. The code looks very non-idiomatic for Java, of course, but with care can be made pretty readable.

[robinei]

Ideally arrays of primitive values like `long` to store the bytecode represenation for proper good performance. Then use bitwise manipulation to access "fields"

[bruce343434]

At this point, why not just use C or C++ since you are already writing it like that? Gets rid of the whole middleman.

[gjadi]

Because you get all the nice tooling around the JVM + safety of running inside the JVM.

See https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... / https://news.ycombinator.com/item?id=24895395

> An improvement can be discussed in the morning, and be implemented, tested and released in production in the afternoon.

[larsga]

That's what we did. Still no luck.

[brabel]

What are the bottlenecks according to the profiler?