This week's book giveaway is in the Artificial Intelligence forum.
We're giving away four copies of Pragmatic AI and have Noah Gift on-line!
See this thread for details.
Win a copy of Pragmatic AI this week in the Artificial Intelligence forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

JAVA INTERPRETER  RSS feed

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 396
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 144
Java Redhat Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
Peter Haggar
author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!