Overhead of Interpreter without JIT

[Christian]

Hello

I have a rather theoretical question..

Imagine a jvm like the newly released squawk being used on a small
device that has a harvard architecture. So JIT compilation is not
possible and everything has to be interpreted. What would you estimate
the overhead of bytecode execution to native code?

Christian

 

[Owen Jacobson]

Hello

I have a rather theoretical question..

Imagine a jvm like the newly released squawk being used on a small
device that has a harvard architecture. So JIT compilation is not
possible and everything has to be interpreted. What would you estimate
the overhead of bytecode execution to native code?

Why estimate what you can measure? Most JIT-capable JVMs have some
method for controlling what gets compiled when. For example, with
Sun's JVM, there are -X options. In Sun's Java 5 JVM[0], the -Xint
startup option disables the JIT compiler entirely.

You can run your own benchmark using code similar to whatever you plan
on running in the "real world" with and without -Xint turned on.

[0] I'm on a Mac. Check your own docs if you're using Sun's Java 6
JVM.

 

[Arne Vajhøj]

I have a rather theoretical question..

Imagine a jvm like the newly released squawk being used on a small
device that has a harvard architecture. So JIT compilation is not
possible and everything has to be interpreted. What would you estimate
the overhead of bytecode execution to native code?

It depends on the program.

Some things will run at the same speed.

Some things may run a factor 100 slower.

You will need to test your app.

Arne

 

[Roedy Green]

What would you estimate
the overhead of bytecode execution to native code?

Sometimes the hardware executes byte code directly. so you have no
extra overhead. It depends on the impedance mismatch between the JVM
byte codes and the machine architecture.

You can estimate. Just look at some classes to find out what he most
common byte codes are. then write little chunks of machine code that
would do roughly the same thing.

From writing a FORTH interpreter, I discovered the big overhead is the
call mechanism and the next mechanism -- the think that fetches the
next byte code and dispatches it to the code to interpret it. You
work to shave that down to the last cycle, then build your whole JVM
around it.

you could improve the JVM by replacing call instructions with call
leaf instructions -- call a method guaranteed not to call any other
methods.

Ditto using a special code for a call to a native method.