Why Java VMs do not have a Pre-JIT feature?

re: Why Java VMs do not have a Pre-JIT feature?

Mathias Raacke — Fri, 25 Mar 2005 10:59:00 GMT

The UCSD Pascal link doesn't work - 404.

re: Why Java VMs do not have a Pre-JIT feature?

Barry Kelly — Fri, 25 Mar 2005 13:04:00 GMT

"I am wondering why no Java virtual machines do not have something similar these days? "

GCJ (the GNU Java compiler) can compile .class files into executable objects which can then be linked into a .exe file, or even C++ files. Of course, the final exe / library will end up with GC & Java runtime (statically / dynamically linked .LIB) dependencies.

Of course, GCJ executables run slower (but start faster) than executables run under the JIT. In particular, GCJ uses the Boehm conservative GC, which limits its optimization strategies (for one thing, it can't compact since it's conservative).

Also, inferring the correct machine operator to use from the datatypes that are statically analysed and discovered on the stack at that point in the assembly (a fundamental limitation of both JVM and MSIL being that the stack must be the same at every instruction, no matter what path got to that instruction) is trivial, not difficult (especially since the stack type data inferral needs to be done for verification). It's easier than function overload resolution, which is something compiler writers do as a matter of course when implementing a language with that feature.

And yes, I write compilers.

re: Why Java VMs do not have a Pre-JIT feature?

Stephane R — Fri, 25 Mar 2005 15:10:00 GMT

By pre-JITting you are probably talking about ngen.exe right?

ngen.exe can be very bad (premature optimization) since it will create machine code on the machine it's running, for instance at build time, not on the end user machine.

Since ngen is not provided by the .NET 2.0 runtime (neither with previous runtime versions by the way), there is no way you are going to ngen your app as a post-install step.

I must have missed something really obvious...

re: Why Java VMs do not have a Pre-JIT feature?

Stephane R — Fri, 25 Mar 2005 15:11:00 GMT

Oops, sorry. ngen.exe is with the runtime dist.

re: Why Java VMs do not have a Pre-JIT feature?

theCoach — Fri, 25 Mar 2005 16:37:00 GMT

Back in the heady days of Java as silver bullet/panacea, one of the pillars of why Java was the end all be all was Write Hurriedly Once\Run Everywhere, and part of selling that was that JIT was really fast, and that they could (theoretically, in the next release) use runtime information to make the JITted code faster.
Part of the culture of Java is still the devotion to machine independence.
There are probably some technical reasons that I do not understand as well, but I think it would be hard to dismiss the white hot anti-Microsoft fires in which Java was forged.

re: Why Java VMs do not have a Pre-JIT feature?

Adi Oltean — Fri, 25 Mar 2005 18:40:00 GMT

>>> GCJ (the GNU Java compiler) can compile .class files into executable objects which can then be linked into a .exe file, or even C++ files.

Yes, I knew about GCJ (I should have mention it). But I don't consider it a runtime. It's just a compiler. So you lose all these advantages coming from a runtime environment (you cannot re-JIT if you detect a certain usage pattern over time, etc).

re: Why Java VMs do not have a Pre-JIT feature?

Adi Oltean — Fri, 25 Mar 2005 18:42:00 GMT

The UCSD link is working now.

re: Why Java VMs do not have a Pre-JIT feature?

Junfeng Zhang — Fri, 25 Mar 2005 19:00:00 GMT

ngen.exe is in .Net framework redist. Check your framework directory.

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\ngen.exe

Java5.0 has introduced Java Class Data Sharing concept. Not the same concept, but similar result. It is very limited though.

Java was never popular for client side applications. That is probably why Sun does not do ngen.exe.

But all are just speculations.

re: Why Java VMs do not have a Pre-JIT feature?

James Arendt — Fri, 25 Mar 2005 20:10:00 GMT

Pre-JIT can help with load time, but the better performance optimizations typically happen at runtime. The Java camp seem to be more interested in actual runtime performance, not loading performance.

The usual example that I've seen floated about is the performance of the JVM's virtual method calls vs the CLR's. The JVM can inline some virtual method calls at runtime. If it realizes the optimization would not benefit the program any longer, it backs it out. Whereas the CLR currently does not bother with even attempting that optimization. Which, considering there are lots of virtual method calls, is unfortunate.

The general idea is that a good JIT can determine more about the execution of your program than a pre-compiler can.

re: Why Java VMs do not have a Pre-JIT feature?

Nicholas Allen — Fri, 25 Mar 2005 20:15:00 GMT

I'll go out on a limb here and guess that for their particular circumstances they decided that adding support for pre-JITing of user code was more expensive relative to the customer benefit that it would provide than other features under consideration for this release cycle.

Antimail Why Java VMs do not have a Pre JIT feature | Menopause Relief

Antimail Why Java VMs do not have a Pre JIT feature | Menopause Relief — Tue, 09 Jun 2009 03:02:30 GMT

PingBack from http://menopausereliefsite.info/story.php?id=1536