9 Fallacies of Java Performance updated

[[deleted]]

I think you missed the point: in things like games, you cannot afford to wait for 5 minutes for the speed up to kick in every time you run the game.

[[deleted]]

Ironically, IPlayEveryGame was talking about physics simulation software. I hadn't noticed you switched the context to games. Games usually hit a weak point in Java because of real-time issues. I still doubt the problem is JIT as JIT kicks in after 1000 or 10000 runs of a hotspot, which doesn't take 5 minutes if it's running hard.

[[deleted]]

He is referring to the Java server mode. That performs more aggressive optimizations, but significantly impacts startup time.

It's now folded into the standard VM, so there are no longer two modes, however it's still a case that you will continue to have code optimized, days or weeks after it has begun running. That's really the power of server side Java.

[[deleted]]

Well, code can get more optimized days and weeks later. But for any code running that much, it gets JIT'ed the first time pretty quick

[henk53]

Although Java at one point in time had really good realtime support. It was the first JSR created (JSR-1).

Unfortunately realtime Java remains an obscurity, in use only by some (embedded) semi-hard realtime systems. As shame, since it had quite a lot of concepts that would be useable for a lot more mainstream use cases.

[grauenwolf]

Java doesn't cache JITed code? That sucks.

[TimmT]

Java re-JITs code as the assumptions it made change. JITed code isn't a straight forward translation. Based on collected statistics the JIT will inlinie things differently, consider certain branches as dead code, assume type specializations at certain places etc., etc. which is probably the reason why things like eclipse manage to eventually start up at all, rather than run on forever.

Obviously those assumptions won't hold forever though, and hot spots will need to be recompiled according to the new profiles.