JAVA INTERPRETER

[PRITAM POTNIS]

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

[Michael Ernest]

The runtime interpreter loads a series of property values, include os.arch, os.version, and so on, that specify the hardware/OS platform. It's worth thinking of the runtime interpeter almost like a device driver -- it's "top half" manages the logical abstractions of running bytecode, while the "bottom half" takes care of converting instructions to what the machine layer understands.
For more sophisticated calls, the interpreter relies on local libraries and native methods to handle the bulk of the logical-layer work.
-----------------
Michael Ernest, co-author of:
The Complete Java 2 Certification Study Guide
[This message has been edited by Michael Ernest (edited December 27, 2000).]

[Peter Haggar]

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