Forums Register Login

JIT Compiler

+Pie Number of slices to send: Send
Hi all,
I have read that the JIT compiler converts the bytecode into the native platform code so that the execution becomes faster.But if this is the case,why is the JIT compiler used optionally?I mean,how does the JVM works if JIT compiler is turned OFF?how is the bytecode converted to machine code then?
2
+Pie Number of slices to send: Send
It's not - the bytecode is then interpreted by the JVM. The reason JIT-compiling is optional is that compiling does not take place automatically. Only if the JVM (or rather, its HotSpot compiler) determines that first compiling a method and then executing it natively, is faster than interpreting it, only then is it compiled. For example, methods that are only run once generally are not compiled to native code. So at any given time, the JVM runs a mix of native and interpreted code.
+Pie Number of slices to send: Send
Thanks Tim! Nice explanation.
Learnt something new!
+Pie Number of slices to send: Send
The JIT compiler is normally on; it's not some optional feature that you explicitly have to turn on to be able to use it.

It is possible to turn it off, but normally you don't want to do that. Reasons for turning it off might be for debugging, if you suspect that a bug in the JIT might be causing your program to run incorrectly. (This would be a very unlikely cause for your program not running correctly).
+Pie Number of slices to send: Send
Hi Sudarshan,

I think you might know that JVMs can be implemented in various ways. It can be implemented in software for some OS, in web browser or in hardware in a chip which is designed to run java programs. If JVM is implemented in software, the java interpreter interprets the bytecode operations one at a time. For faster execution JIT is used.

Here, the first time a Java method is invoked, the bytecodes for the method are turned into native machine language for the host system. These operations are then cached so that subsequent invocations of a method are performed using the native machine instructions and the bytecode operations need not be interpreted all over again.

However there's a faster method exists. It is faster to run JVM on hardware on special java chip which executes Java Byte code operations as native code. Hence interpreter or a JIT compiler not required.
+Pie Number of slices to send: Send
 

Debajyoti Kundu wrote:the first time a Java method is invoked, the bytecodes for the method are turned into native machine language for the host system.


This is not correct; please see the previous posts.

It is faster to run JVM on hardware on special java chip which executes Java Byte code operations as native code.


While that is a theoretical possibility, it plays no significant role in practice, though.
+Pie Number of slices to send: Send
 

Tim Moores wrote:

Debajyoti Kundu wrote:the first time a Java method is invoked, the bytecodes for the method are turned into native machine language for the host system.


This is not correct; please see the previous posts.


How can you tell it's not correct? When you compile a java program for the first time the .class file is generated. Unless there's no change in your code, subsequent compilation don't perform any modification to the class file.

It is faster to run JVM on hardware on special java chip which executes Java Byte code operations as native code.


While that is a theoretical possibility, it plays no significant role in practice, though.


This is also not true. You can google JVM implementation in hardware or you can also refer virtual machine section of Galvin.

 
+Pie Number of slices to send: Send
 

Debajyoti Kundu wrote:How can you tell it's not correct? When you compile a java program for the first time the .class file is generated. Unless there's no change in your code, subsequent compilation don't perform any modification to the class file.


The statement of yours I quoted said nothing at all about compiling Java source code to class files - it said that a method is turned to native code when it is first executed, which is 100% false. You need to check your facts more carefully.

This is also not true. You can google JVM implementation in hardware or you can also refer virtual machine section of Galvin.


It is absolutely true. Please read carefully what I wrote: I didn't say that hardware implementations weren't possible or that they didn't exist; I said that they played an insignificant role in practice. Do you really want to dispute that statement?
+Pie Number of slices to send: Send
 

Tim Moores wrote:

Debajyoti Kundu wrote:How can you tell it's not correct? When you compile a java program for the first time the .class file is generated. Unless there's no change in your code, subsequent compilation don't perform any modification to the class file.


The statement of yours I quoted said nothing at all about compiling Java source code to class files - it said that a method is turned to native code when it is first executed, which is 100% false. You need to check your facts more carefully.


Sorry for the confusion. By the word method i did not mean java method. I should save been more specific about it.

This is also not true. You can google JVM implementation in hardware or you can also refer virtual machine section of Galvin.


It is absolutely true. Please read carefully what I wrote: I didn't say that hardware implementations weren't possible or that they didn't exist; I said that they played an insignificant role in practice. Do you really want to dispute that statement?


I don't completely agree with this notion, as it is one of the most hot topic. Surely there it's implementation is not very wide but there are some good example like PicoJava

 
Joel Salatin has signs on his property that say "Trespassers will be Impressed!" Impressive tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1456 times.
Similar Threads
Doubt regarding java compilation
using temporary variabel
JIT and related doubts.
Bytecode
JIT Question
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 16:00:25.