4

I know that javac compiles the *.java files into *.class files , the content of these files is called bytecode.

I assumed each bytecode was translated to an assembler equivalent like ADD or SUB or whatever. If this is true then the final result of the JIT and my intepreter should be the same assembler instructions and at this point I don't see why I would need my /usr/bin/java interpreter.

Please correct if any of my statement is wrong.

Improve this question
6
  • The Wikipedia article about Java answers your question pretty good. For more details I suggest you start with the official documentation Commented Feb 16, 2015 at 15:22
  • I've refined the question to the part that was mention in the title. Voting to reopen. Commented Feb 16, 2015 at 15:28
  • Why reopen? Similar questions have been asked here and here and have been closed as not constructive. Whats different with this question? Commented Feb 16, 2015 at 15:36
  • Similar but they are not duplicates in my opinion. This question boils down to Are bytecode instructions translated directly to corresponding assembly instructions. Commented Feb 16, 2015 at 16:09
  • 1
    Java is almost as fast as C code (once the JIT dealt with it). So even the title is not completely right. I think the question should first ask if indeed JIT compiled Java code is slower, then ask why. Commented Feb 16, 2015 at 16:52

1 Answer 1

Reset to default
2

Java bytecode is a fairly high level language and there's far from a 1-to-1 relation to assembly instructions. Here are a few things that come to mind:

  • Garbage collection - This is a guarantee of the JVM and typically not considered when talking about programs written natively.
  • Classes - Bytecode still has classes and class hierarchies (including polymorphism, virtual method calls, etc)
  • Type safety - Although there exist type safe assembly languages, the bytecode type system is far more complicated than any ordinary assembly language.
  • Array index checks - Each array access needs to (directly or indirectly) be governed by out of bounds checks. A high level feature that must be dealt with by the VM.
  • Null pointer checks - Many bytecode instructions can implicitly throw nice exceptions such as NullPointerException. The "native counterpart" is to fail silently or segfault.
  • Exception handling - Exception handling in general have performance implications. Sure, native languages such as C++ do support exceptions, but many C++ projects avoid using them for performance considerations.
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

aren't these operations above mentioned by you handled by assembler as well ?
If you compare native code (by that I assume you mean code written in for instance C) the responsibility of freeing memory is on you as a programmer. You will typically perform better than a garbage collector. Array index checks can often be skipped since you as a programmer may have a better understanding of the code / knowledge of a larger context than the JVM has. Same goes with null pointer exceptions.
could you please tell me then , when does my bytecode get interpreted and when does it get compiled ? I read the man java , and I saw the Xint which disables compilation and Xbatch almost the same.
This depends on which VM you're using. JRockit compiles everything up front IIRC, Hotspot runs the interpreter during warmup and compiles parts of the code that makes sense to compile.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.