Submitted by With the build 59 of Mustang (Java 6), Sun’s Java Hotspot Client virtual machine gained substantial performance. According to some numeric intensive tests, the new register allocator mechanism provide the Client virtual machine with an average of %58 higher performance.
Java 6 HotSpot Client Gets Faster
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Congratulations! Now Java applications will only feel five times slower than native applications, as opposed to ten!
Run the C version of Scimark on similar hardware and you’ll see that the Server JVM’s performance is pretty much on par with native code.
Yeah, I don’t care about benchmarks or any fancy numbers — Java applications take longer to start, are much less responsive than native apps, and even take longer to close. An application shouldn’t feel laggy on a 2.4 GHz Athlon 64 with 2 GB of RAM — but it does, and I blame Java.
Come on guys, don’t mark him down so savagely, he does have a sense of humor and he’s only kidding. No-one needs to get really offended by this one.
He does indeed have a sense of humour… but nearly everyone around here does not… thats why nearly every post he sends gets sent down
Yeah, and the fact alone that only a few of us here have a sense of humour makes things 5x funnier.
It’s kind of like telling a crowd of stupid people off in what sounds like a joke, but no one gets it except you and your buddy. You laugh *that* much harder.
I wonder how that is possible since the java byte code interpreteris doing more ? In theory it shouldn’t .
http://en.wikipedia.org/wiki/Just-in-time_compilation
Edited 2005-11-11 07:40
The SciMark benchmarks are the perfect situation for a JIT compiler. All of the kernels are tiny (a few pages of code), with tight inner loops and written in a very low-level style. That means the first-time the inner-loop is run, it gets translated to machine code, then the JIT gets out of the way and the rest of the benchmark runs natively.
I wonder how that is possible since the java byte code interpreteris doing more ? In theory it shouldn’t .
Why not? After the JIT is run, you’re essentially running native code. Of course, the start-up time will be longer, but after the JIT is run you should get speed that is occasionally faster than native code (method devirtualization, etc).
Why not? A JIT compiler *IS* a *COMPILER*. There will be a slight startup delay because of the time required for compiling (remember bytecode is compact and easier to compile than source code) but that is overcome by the fact that dynamic optimisations can be done by recompiling the code as conditions change.
Well, it’s not quite so simple. A JIT compiler is a compiler, but its also one with very demanding time constraints. It cannot, in general, afford to do very expensive optimizations. The client JVM, in particular, is forced to make compromises that ensure reasonable loading time. For example, consider register allocation. The traditional algorithm, graph coloring, takes a significant amount of time, and is quadratic in the number of life ranges (basically, quadratic with code size). A newer algorithm exists, called linear scan, that is basically linear with the number of live ranges. However, it generates code that is about 10% slower than graph coloring. In general, the best optimization algorithms are an order of magnitude more expensive than the lesser ones, so JITs usually cannot afford to use them.
JIT compilers can recompile methods with stronger optimisation in a background thread when the app is idle.
That presupposes a GUI application, which generally doesn’t need the performance anyway. Performance-sensitive applications generally don’t spend a lot of time being idle.
My main complaint with JITs is that they solve a problem that doesn’t need solving. Cross-platform distribution just requires the application to be delivered as bytecode, it doesn’t require it to be recompiled every time it is run. Why not just compile at install-time and cache the resultant code?
This isn’t entirely true. When dynamic optimization is a win over purely static compilation cached precompilation won’t afford the same benefit. Caching static compilation on installation has some advantages for languages that target a bytecode (and the disadvantage of taking all of that time to do a whole-program compilation which on certain targets or give certain-size programs could be pretty annoying, especially if we’re considering aggressive optimization) and might be better served simply by an installer capable of choosing a variety of optimized precompiled binaries, but it doesn’t obtain all of the benefits of dynamic optimization (which could be as useful for the output of a C compiler as the output of a Java compiler). That isn’t to say that caching precompiled units is a bad idea, but rather it doesn’t solve the same problem.
The previous sentiment about the disadvantages of relying solely on runtime compilation as it pertains to the expense of performing certain optimizations I support fully, though.
I keep hearing about all of these dynamic optimizations that are possible, but I’ve yet to see such a beast in action. Java seems to do some of the basic stuff, like resolving method call targets, but its optimizations are quite simplistic everywhere else (eg: its just getting escape analysis). Is there actually a JIT that makes a credible claim to beating traditional static optimizers?
‘Beat’ unless you mean ‘in conjunction with’ is somewhat inappropriate. DynamoRIO showed promise in improving the efficiency of optimized statically-compiled software.
In the partial evaluation camp, Calpa in conjunction with DyC showed promise from a slightly different perspective. Then of course there’s the runtime optimization of especially dynamic languages like Self or Python (with Psyco), where meaningful static optimization is fun for the whole family.
There are numerous avenues where runtime analysis will provide better performance than not performing it, regardless of the sophistication of Java. Though it warrants mention that escape analysis has been applied in Java research to stack allocate objects and remove unnecessary synchronization since about ’98-’99 with various implementation strategies with tradeoffs in precision and speed along the way.
Well, originally Java was to be used over the internet. So you would compile your applet to bytecode, and clients would download the bytecode to run the applet. There wasn’t really much point in storing the native code.
My main complaint with JITs is that they solve a problem that doesn’t need solving. Cross-platform distribution just requires the application to be delivered as bytecode, it doesn’t require it to be recompiled every time it is run. Why not just compile at install-time and cache the resultant code?
Microsoft is already doing this with their GAC for .NET. And there’s nothing stopping Microsoft or others to run a profiler on frequently used assemblies and then just AOT that bytecode using the profiler information, thus doing the optimization based on some usage pattern, but just not a runtime.
> That presupposes a GUI application, which generally doesn’t need the performance anyway.
Well they shouldn’t need it except that people complain because GUI apps written in Java are *slow*.
I remember that in Solaris9, Sun replaced the old GUI admin tools by newer one written in Java and they were *slow as molass*.
So slow that it made me learn Solaris command line tools to avoid using those crappy tools..
As for your idea of compiling at installation: it isn’t very pratical: it may take hours to compile a big application..
Another possibility would be to save the generated codes instead of just recompiling over and over and dropping the result.
😉
Hey Poo what program are you trying to run?
Also I am looking forward to Mustang finally being released! There are a lot of features to catch up on!
Java’s main issue (IMO) is that it eats lots of ram….6.0 may be faster, but what about memoyr comsumption?
http://weblogs.java.net/blog/xiaobinlu/archive/2005/08/perception_r…
Does anyone know why Sun chose a stack based bytecode instead of a register based bytecode?
If the bytecode was based on eg. 64 virtual registers it would be possible to do good register allocation on the bytecode at compile time. Then the bytecode would end up using a subset of the virtual registers (and usually only a few registers). The JIT-compiler would only have to spill registers that cannot be mapped to a register in the native architecture. The registers could even be ordered so the registers with lower numbers were the most used, and should not be spilled.
because stack based VMs are well explored: p-code is stack based, too iirc, as are the other VMs/VM-alikes sun worked on: Forth/FCode in OpenFirmware, Postscript.
stack based is a bit easier, too, esp. the way sun did it in java (where you can access more than just top of stack)
also, you will make some assumption about the target platform when you build a VM that’s too similar to the platform you usually work on, eg. about the purpose of registers, addressing modes, etc.
The advantages of a stack machine are that in an interpreter you don’t have to pay for the expense of decoding the operands of an instruction, having a smaller bytecode, and the frontend compiler can be simpler. The disadvantage is that you have to pay more in performance and complexity of the JIT compiler to perform register allocation, and in various cases an interpreter will have to process more instructions. There’s nothing about a register machine that requires you to define it in terms of one of the target platforms, so that’s not exactly an advantage of a stack machine.
(This is not an exhaustive list of pros and cons.)
Edited 2005-11-11 12:47
Does anyone know why Sun chose a stack based bytecode instead of a register based bytecode?
Well for one thing, Java was originally intended to be executed on Sun-built Java processors for set-top multimedia boxes. These processors were stack-based. The interpreted VM was just a technology preview. It just turned out that people were more interested in the interpreter that ran on their own hardware than they were in buying more special-purpose hardware. So Sun had to add a JIT compiler to make it faster, and then Java was running on stock hardware even faster than it would have on the processors.
Now, with Java-accelerated processors showing up in cell phones and such, things are finally turning out the way that Sun had intended, albeit with Sun as a technology licensor rather than a manufacturer.
Whenever these types of news items come up, I begin wondering if it is possible at all to run Client-targeted apps with the Server HotSpot VM. Has anyone dones this? I understand that the Server VM is more memory intensive and has a longer startup time, but if the performance is so much better why not give it a try. Are there license fees that come into play with the distributing the Server VM with an app also?
Just wondering.. Maybe someone has experience with this.
-pd
The server VM will run the same programs the client does, only it runs a lot more optimizations at startup.
To use it add the -server tag to the java commandline. There’s also a config file somewhere that lets you set it to the default. And I think you need to have the SDK, not just the JRE.
Edited 2005-11-11 18:56
Java’s main issue (IMO) is that it eats lots of ram….6.0 may be faster, but what about memory comsumption?
This is the main issue I have with Java. The two Java applications I use a Java server and Limewire desktop applications both take a long time to startup. The server literally takes long enough that I can walk into the kitchen, put in a new filter, add coffee, click the start button, wait 4 minutes until the coffee is ready, and finally come back just in time to see that the server is ready. The memory consumption of Java applications is way out of control. People always tell me just run that server on a 4 Gig server. Ugh, is that really necessary just to get a simple server up and running?
Java is slow to start because every app you launch launches it’s own virtual machine. Basically it’s like launching your operating system everytime you launch an application.
If you have a VM running an just instantiate a few classes that represent a new program then it’s instantaneous. Just try something like JOS. I guess the OS itself should offer a better java integration.
The first thing I think when I read that something got twice as fast (and I read it about java every release) is:
Damn, how awfully slow the first version must have been.