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.

Oleg
  • 1,479
  • 3
  • 21
  • 42
  • The [Wikipedia article about Java](https://en.wikipedia.org/wiki/Java_(programming_language)#Practices) answers your question pretty good. For more details I suggest you start with [the official documentation](https://www.java.com/en/about/) – Gerald Schneider Feb 16 '15 at 15:22
  • I've refined the question to the part that was mention in the title. Voting to reopen. – aioobe Feb 16 '15 at 15:28
  • Why reopen? Similar questions have been asked [here](https://stackoverflow.com/questions/13611634/c11native-code-vs-javabytecode) and [here](https://stackoverflow.com/questions/48144/what-are-advantages-of-bytecode-over-native-code) and have been closed as not constructive. Whats different with this question? – Gerald Schneider Feb 16 '15 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*. – aioobe Feb 16 '15 at 16:09
  • @aioobe yes , it was a nasty game of words from my side ,sorry. Firstly I got the wrong idea that bytecode was mapped 1 to 1 to assembler code , as a result I asked a false question. – Oleg Feb 16 '15 at 16:13
  • 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. – NoDataDumpNoContribution Feb 16 '15 at 16:52

1 Answers1

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.
aioobe
  • 413,195
  • 112
  • 811
  • 826
  • aren't these operations above mentioned by you handled by assembler as well ? – Oleg Feb 16 '15 at 15:17
  • 1
    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. – aioobe Feb 16 '15 at 15:24
  • 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. – Oleg Feb 16 '15 at 15:53
  • 1
    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. – aioobe Feb 16 '15 at 16:08