I wanted to know how the interpretor in Java works internally and how is it different from the rest . example when i run a C program first i have to compile it so that it object code will be created and then i will run it for the exe. now when i write a program in java and compile it so that bytecode will be created,this bytecode will remain the same for all operating systems. it is then the job of the interpretor to convert the bytecode into machine instructions for that particular processor.
My question is how does the interpretor converts the bytecode into machine instructions for the particular OS and the processor
how would the interpretor know which is the particular OS and how to interpret the bytecode according to that OS
Hi Pritam, Whatever u've written is bsolutely correct. Now to answer ur question I'd like to tell u that. - java is platform dependent till bytecode only. The interpreter that interprets the .class file is actually an exe meant for that particular platform only.and it knows the m/c codes for the platform it is meant for.
The interpreter that work for windows won't work with sun solaris and so on. hope this answer your question. regards Deekasha
The interpreter does not convert bytecode to machine code. That is the job of the JIT or Hotspot. There are 3 common execution environments in Java: Fully interpreted, JIT, and Hotspot. 1) Fully interpreted - The interpreter interprets the bytecode for each method for every execution of the method. The JVM calls routines that perform the task of the bytecode for the platform it is written to. A JVM, basically, has a platform independent part and a platform dependent part. For example, if you code a synchronized block in Java, the compiler generates the monitorenter and monitorexit opcodes. The JVM's platform independent interpreter calls platform dependent routines to acquire and release the monitor for the platform it is written to. 2) JIT compiler - When .class files are loaded, all of the bytecode is compiled to native machine code at runtime. The native machine code is stored in memory and the bytecode is no longer used. The advantage to this approach is that you normally get much faster execution speeds, but slower load times, because all the code is being compiled when it is loaded. The disadvantage to this approach is that you are compiling everything, even methods that are only executed once. Therefore, you can spend more time to compile a method than it would take to simply interpret in once. 3) Hotspot - When .class files are loaded they are initially interpreted. Hotspot then performs some analysis on the code and determines the performance critical methods. These methods are then compiled to native machine code, leaving non-performance critical methods interpreted. The advantage to this approach is that you are only spending time compiling performance critical methods and not spending time on the rest. A disadvantage to this approach is that Hotspot requires "warmup". You will not see a performance improvement with Hotspot unless you let it run awhile so it can perform its work. Almost all JVMs today come with a JIT or are enabled with Hotspot. Fully interpreted VMs are not common in the desktop or server environments. They are found in the embedded world due to the additional memory and storage requirements of JITs and Hotspot. Peter Haggar ------------------ author of: Practical Java
Hello Peter is this the *ONLY* reason why JAva is called a interpreted language.Please throw some light on this aspect of the lnaguage ... Wonderful Explanation you had provided .
Originally posted by Peter Haggar: 1) Fully interpreted - The interpreter interprets the bytecode for each method for every execution of the method. The JVM calls routines that perform the task of the bytecode for the platform it is written to. Peter Haggar
[This message has been edited by sunil choudhary (edited January 06, 2001).]
"Learning is weightless, a treasure you can always carry easily." -Chinese Proverb
posted 18 years ago
Because Java was originally fully interpreted (before JITs were common) it was *incorrectly* called an interpreted language. Java is not, nor has it ever been, an "interpreted language". It is a language that was once most commonly executed with an interpreter, but that is not required. You can have a C interpreter, but that does not make C an "interpreted language". You can compile Java code right to machine code with a static compiler, just like you do with C or C++. I hope this helps, Peter Haggar ------------------ author of: Practical Java