EJB design: Skipping JVM Interpreter
I fully agree with Javas basic philosophy
Write once and run anywhere .........
With EJBs coming in picture, I have a gut feeling that once the project development is in progress same time the team has the hardware configuration where the project is supposes to be deployed. With this in consideration, should sun people come with add on jdk functionality which will compile java code to final platform depended byte code (here byte code is something what a c++ code will generate). What I am trying to point here is that, with .Net coming with a bang and there promises to deliver more efficient platform for enterprise world, java is still leading in the race, even though the code has to go through interpreter. But if you look at the practical scenario most of the projects are deployed on known platforms and will run on those platforms for many years to come. (Considering that no organization will switch the hardware in 1 year).
With this kind of practical situation sun should provide an extended JDK kit for generating platform specific executable compilations and hence in runtime can skip interpretation mode and finally result is twice the performance as of the current readings.
Unfortunately I have no comparison data at hand but I guess this problem has been fairly resolved by JIT compilers already. Don't you think so?
Can you send me pointers for more information on this, is there any JIT provided by sun ?
I guess I will like to see some app server giving this feature as a buildin feature, and as and when the code is being used the final compiled file set is produced and later used. hence part of code which is first run will go through interpreter and then have a copy of final compilation and in second run it will skip interpreter and start using final compiled version.
The end result will be visited part of application (or most visited part of application) will run on final compilation and the new part will still run through normal jvm route.
It's not a matter of a server. It's part of JVM itself (though you may tune your server taking into account your circumstances). No "final compiled file set" is ever needed since all optimisation is done in realtime according to the current activity. It's possible to say that to get the system working on a high performance level the JVM needs some time. But it happens on an initial stage.
I found an article giving first insight on the matter. Hope it helps:
JVM actually does it in the back-end. Once a peice of code is executed for 1500 times, JVM complies the code into native code to improve the performance. The number 1500 is default. This can be configured using -XX:CompileThreshold JVM option.
For more details