JIT Question

Greedy thomas

Ranch Hand

Posts: 37

posted 13 years ago

Hello, I was reading about the JIT compiler from an earlier post and followed on one of the links. I have a few questions regarding the JIT. 1. Does the JIT come with every JVM for all platforms i.e. is the JIT a part of the JVM. 2. What do they mean that 'if the JIT is present, the code will run faster' - if the JIT is a part of JVM, then won't it always be present. Can you separate it from the JVM and if so, why would you do that. 3. Using JIT the code runs faster because the JVM passes the .class file to the JIT. Does not not create a delay and slow the execution process because now first the JVM will parse the bytecode and then the JIT will execute it in the native code. Isn't there a performance issue here. 4. How would you know if you have a JIT installed and how would you know it is being called. I apologise if these questions seem trivial but I'm starting off new in Java. Thanks In Advance, Rajesh.

I can't answer all of your questions however basically two forms of java exist. The first is a JRE which is the Java Runtime Environment. This would be installed on the client or end-user pc. I don't believe the compiler exists in this environment. Secondly you can have the JSDK, which is the Java Software Developer's Kit, this obviously is used by the developer and would contain the compiler along with the additional tools and features. You might look at java.sun.com and see if you can find a feature list between the two installations.

Actually, the JIT Compiler or Just In Time Compiler has been a core part of Sun's VM for a while. (I think) Prior to 1.3, JIT had to be switched on when executing a Java Application and I think there may have been a checkbox for it in IE settings. However, 1.3 and up default to using JIT. There is of course a switch to turn it off if you want to.

I just found the below simple explanation from here You first run "javac", the Java Compiler, which turns the Java code into what is known as "bytecodes" and puts them into the "hello.class" file. This class file can then be interpreted on any machine which has a Java Virtual Machine on it. The key word here is "interpreted". The Java Virtual Machine processes each of the bytecodes in the .class file and executes them. This is similar to what other interpreted languages do, such as Basic, LISP, and Smalltalk. When a JIT is present, the Java Virtual Machine does something different. After reading in the .class file for interpretation, it hands the .class file to the JIT. The JIT will take the bytecodes and compile them into native code for the machine that you are running on. It can actually be faster to grab the bytecodes, compile them, and run the resulting executable than it is to just interpret them. The JIT is an integral part of the Java Virtual Machine, so you never notice it's there, except your Java runs faster. Some environments allow you to choose whether or not to JIT code. Java is a dynamic language, so you are not allowed to "statically" compile all the .class files into machine code until they are actually called. Thus the JIT is really "just-in-time", since it compiles methods on a method by method basis just before they are called. If you call the same method more than once, the JIT'd code can really pay off as you do not have to re-JIT the method and can simply re-execute the native code. Does it make sense to always JIT code? No, not always. Sometimes JIT'd code does not run any faster than interpreted code. If the Java Virtual Machine is not spending its time interpreting bytecodes, then JIT'ing the bytes codes will not speed things up. Although it is rare, things might slow down since you are spending the time compiling the bytecodes when you could have been interpreting them.