What is the overhead of a method call in a good Java VM?

Question

Can someone come up with a disassembled machine code assembler listing?

I mean there must be some overhead compared to the normal function call in C.

The VM needs to track calls to find hotspots and when it uses compiled code it needs to provid ways to change the compiled method on fly if a new loaded class requires a recompilation.

I guess there is also a return stack overflow check somewhere.

EDIT: I think i should mention that i'm not a java programmer but a compiler writer and want to find out why java applications are so slow while the java micro benchmarks are comparable to native compiled code. So looking at some the details is important for me here, even if they take only a few dozend nanoseconds and a few additional instructions.

Answer 1

Java doesn't compile directly to machine code, it compiles to bytecode which is then either interpreted or compiled to machine code at runtime--I have no idea how to get to the machine code at runtime, I just imagine it as this huge mass of shifting, changing bytes that just ends up executing DAMN quickly and reliably.

A small method call should compile out completely at runtime. Even a large method call can be written as in-line machine code by the VM if enough references can be resolved or ignored.

Using Final can help a lot because it gives the VM hints as to how it might optimize even more.

Since a method call can actually compile out completely and at best has a minimal cost anyway--you really shouldn't worry about it. Just code your best and worry about performance problems when you have a failing performance spec (at which point spot-optimizing will do MUCH better than trying to eliminate method calls across your code, ruining your codebase for everyone involved).

Note that because of the runtime analysis, it can actually be faster in some very rare cases than similar code in C (The c compiler won't profile at runtime and hand-optimize your code for you, you have to do all that yourself).

Answer 2

This is heavily dependent on the JVM you are using (especially when using one capable of just-in-time compiling to native code), since the optimizations performed over your code will ultimately determine this.

For instance, the JVM may decide to inline your method, and then you do not have calling overhead at all. If the method is not inlined, but still compiled into native code, you have an equivalent overhead to calling a method/function using a pointer in C/C++, plus the machine-specific requirements (for instance, setting up stack stace, arguments, epilogue/prologue). This should sum up to about the time to execute 10 to 30 native instructions, but it is an approximation---you should measure this if really important.

Figures should be very different if you are using a interpreting-only JVM, possibly with much higher overhead (never checked it myself, but if I had to guess, I'd bet on one extra magnitude---so around 100 to 300 instructions).

Answer 3

In the updated question, the OP wrote this:

I think i should mention that i'm not a java programmer but a compiler writer and want to find out why java applications are so slow while the java micro benchmarks are comparable to native compiled code.

Then in a comment the OP wrote this:

... i found that method calls in Java 1.3 SUN VM (the last i ever used) were extremely expensive almost doubling the speed as inlining was obviously working far far from perfect.

I think that the real problem is that your view that "Java is slow" is based on experiences with a really old release of Java. The java JIT compilers have improved significantly in the 9 years since Java 1.3 was released.

So looking at some the details is important for me here, even if they take only a few dozend nanoseconds and a few additional instructions.

If you are (by your own admission) a not a java programmer, but a (non-Java I assume) compiler writer, why are these details important to you?

UPDATE: I found this page on the Sun Wikis that may help. It applies to Java 7 which is only available as development builds, but there may be enough clues to help you disassemble JIT compiled code for current Java releases.

Answer 4

Well i never programmed Java since 1.3, but i'm using Eclipse, Netbeans and IntelliJ frequently and all of them are so slow compared to native GUI programs.

I'm not sure that I'm clear on even how to generate statistics for the performance of a GUI--do you measure the time taken to perform a specific task, use automated testing, or is this one of those situations where you sort of eyeball it and say "it's slower/faster than program X". I'm no expert on native GUI programs, but I do know that GUIs in Java often appear slow not because Java itself is necessarily slow, but because the GUI writers failed to construct a responsive GUI--putting long-running tasks on the Event Dispatch Thread, to name one example. In the absence of well-constructed comparison tests, it's hard to tell what's the fault of Java and what's the fault of bad GUI programming.

To answer your question, though, Bill K mentioned the Computer Programming Shootout Game as a source of numerous compiler benchmarks. Another interesting source of statistics for Win32 platforms can be found here.

Answer 5

The point here is that you are comparing apples and oranges. Java compiles at runtime (have you heard of JIT?), so it's not exactly comparable to C which compiles offline. Most of the overhead comes from the time which you don't count in C (the compilation process) and not from the "method call" as you suppose