Re: Java (bytecode) execution speed

Lee wrote:
All other things being equal, we expect an interpreted language to run a bit slower than native machine code.

<SNIP>

At least two people were kind enough to point out that Java uses a JIT compilation system and that in any case the difference of execution time beween a Java progam and a hypothetical compiled version of the same algorithm (or as similar as the two languages allow), would probably be due more to the differences in heap managemant and/or garbage collection than in raw compilation speed.

In that context it becomes plausible that in some circumstances Java might actually run faster than an equivalent C/C++ implementation.

I must be missing an important nuance about Java and JIT.

Perhaps someone can "debug" me on this:

I had thought that bytcode was, so to speak, the "machine code" of the Java Virtual machime. If that were true, I can't see how there would be any room (or any need) for further compilation of the byte code. The byte code itelf would "drive" the VM, taking the VM from internal state to internal state until the computation was done.

But if the bytecode were just a portable abstraction, something "above"
the JVM's machine language but "below" the java source language, that would create the need to compile the byte code "the rest of the way down" to the actual jvm machine language, but NOT to native hardware machine language.

So even in that case, the "compilation" would be down to the VM's machine language, not the actual hardware's machine language.

But all the descriptions I see on the net about JIT talk in terms of compilation to native machine language. I can see how that would work with somethink like say the Pascal p-system, where pascal source would be compiled into "p-code", and then the p-code would either be interpreted or "just-in-time" compiled to native hardware machine language.

My problem is that in my conception, when it is a question of running a virtual machine, the "compilation" would be to that vm's "machine" language and thats as "low" as you could go.

What have I got wrong?
.

Relevant Pages

  • Re: What would you like to know about JRuby?
    ... I often find myself writing jruby scripts in java just ... compilation is basically just a "blob of methods" that are wired up ... public IRubyObject method__1$RUBY$bar; ...
    (comp.lang.ruby)
  • Re: Why not Half Life 3 on Java ?
    ... I'm not a Java guru, ... > Excelsior JET is able to do reasonable "static" compilation. ... >> and pointers. ... > Only legal operator overloading is the operator overloading defined ...
    (comp.games.development.programming.misc)
  • Re: Smalltalk w/o IDE, etc.?
    ... Java crowd was sometimes along the line of, "sure there's a lot of verbosity in Java, but the IDE will generate all that infrastructure for you". ... Java is a compiled language and Ruby is an interpreted scripting language. ... you'd realize that the programmer is shielded from this fact - compilation is transparent and happens on the fly as you modify the program. ... the relative differences between {Ruby, Smalltalk, Lisp}, I think I'll pursue Lisp first, and then learn Smalltalk afterward. ...
    (comp.lang.smalltalk)
  • Re: Java (bytecode) execution speed
    ... At least two people were kind enough to point out that Java uses a JIT compilation system and that in any case the difference of execution time beween a Java progam and a hypothetical compiled version of the same algorithm, would probably be due more to the differences in heap managemant and/or garbage collection than in raw compilation speed. ... the JVM's machine language but "below" the java source language, that would create the need to compile the byte code "the rest of the way down" to the actual jvm machine language, but NOT to native hardware machine language. ... object code - what the programmer wants done, but in a form the computer can understand ...
    (comp.lang.java.programmer)
  • Re: Do you still choose java????
    ... The Java Virtual Machine translates ... the Java Virtual Machine can both interpret ... > delay due to the compilation time. ... > code can benefit the most from machine language compilation. ...
    (comp.lang.java.programmer)