Re: Java (bytecode) execution speed

Lee <leeh@xxxxxxxxx> wrote:
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.

Bytecode is just a file format to represent the actions of a piece of
Java code. Nothing more, and nothing less. It can be used directly, or
it can be converted to a different format.

Early implementations of Java interpreted it; that is, they used it
directly. Actually, implementations of Java on cellular phones and
other embedded devices often still do this because it's more efficient
in terms of memory usage and generally no one does high-performance
computation on a cell phone.

Newer Java implementations (as of 1999 or so) for desktop and server
platforms rarely interpret the bytecode. They translate it into the
native machine language, and let the processor run that native machine
language directly. This is, obviously, much faster.

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.

There is no JVM machine language. Perhaps what's confusing you is there
is no such thing as "the" JVM. There is a JVM for x86, another for x86-
64-bit platforms, another for Sparc, and so on... There are different
JVMs for different operating systems as well, though they often share
most of the JIT implementation. Each of these implementations of a JVM
contains its own different JIT compiler that generates code appropriate
for that processor.

So in the end, the JVM for a particular platform does the transformation
to the native machine language for that CPU, and from that point on it
just runs the code and sits back and waits for the code to call it;
essentially, after the JIT step, the JVM is essentially just a library
that is called by the application code.

--
Chris Smith
.

Relevant Pages

  • Re: Why FC4 using the Jpackage 1.4.2 Java?
    ... No open source JVM currently exists. ... You can register with Sun and go to Sun's Java sight and freely ... run the Java code optimally on the specific platform. ...
    (Fedora)
  • Re: Help me!! Why java is so popular
    ... My point is that those who use Windows already accept bloatware and the ... I think those are the kinds of things which has made Java popular. ... And don't forget about the very fact that with JVM, ... GUI elements are called components and containers, ...
    (comp.lang.java.programmer)
  • Re: Help me!! Why java is so popular
    ... You are basically arguing that "Java is slow because it is slow". ... > Also, a JVM can pay attention to usage, provide caching, adapt at run ... I have no use for unicode in my ...
    (comp.lang.java.programmer)
  • Re: Dusting off an old JVM discussion
    ... I was wondering how difficult it would be to write a JVM in Forth, ... Upon looking at those "opcode" instructions, ... and I think today's PDA's might have more memory ... I imagine those applications written in Java, ...
    (comp.lang.forth)
  • Re: For performance, write it in C - Part 2, comparing C, Ruby and Java
    ... Or is it the fact that after working in Java since '92 you have ... find out about the JVM startup penalty and that any decent benchmark ... would not account for that (only in case you are compairing JVM ...
    (comp.lang.ruby)