Can any1 summarize performance and other benefits from java 6 release…especially the graphic part?
Maybe some links?
Ty vm.
I haven’t really looked at graphical performance yet, but I did notice that ImageIO improved… a lot.
I don’t have the link on me anymore, but I do have this graph.
http://weblogs.java.net/blog/campbell/archive/images/mustang.png
In terms of real loading times, let’s say that mine got slashed by 40% just because of this.
Applets are much nicer in Java 6 they have a nice loading progress thing instead of that horrible grey box, still could be better, more snappy and less freezing the browser but definitely an improvement.
Overall there an optimisations all over it.
www.javadesktop.org has had stuff on Java 6 performance lately. Word is that the performance gain is ‘double-digit’. Here’s 2 recent blogs about it:
http://blogs.sun.com/dagastine/entry/java_6_leads_out_of
http://jroller.com/page/dgilbert?entry=is_java_se_1_6
My experience with Java 6 is that its Direct3D (& also OpenGL) pipeline is now a lot faster (flag -Dsun.java2d.d3d=true from http://java.sun.com/javase/6/docs/technotes/guides/2d/flags.html).
Keith
PS: see Chris Campell’s many blog entries for stuff on Graphics performance. Eliwood’s graph comes from there: http://weblogs.java.net/blog/campbell/archive/2006/01/400_horsepower.html
The best one: http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_perf.html
http://weblogs.java.net/blog/campbell/archive/images/OGLPipelinePerf2.gif
I turned on the Java2D OpenGL flag and noticed that my game went just as smoothly as it did when using LWJGL, and to boot, loading times were faster, even versus the custom TGA loader. Makes me kinda feel bad about spending all that time working on something that Sun’s effectively deprecated for me now, but I’m surprised at how much things have improved since Tiger.
Unfortunately, this was not the case with the D3D tag set to the true, which was about the same performance as plain vanilla Java2D.
A big boost in number crunching performance too. JSquish (pure java s3tc texture compressor) compresses images about twice as fast under jse6 compared to jse5.
For the server-jvm I did a benchmark some time ago which is almost exclusivly algorythmic code:
I find these numbers really impressive especially when taking into account that code mostly reflects the quality of jit generated code and does not use anything else.the jvm provides. Therefor I would expect even better numbers for real world code 
lg Clemens
These statements are incorrect on two counts. First, based on measurements with several benchmarks, the new client compiler (linear scan + SSA) has the same or better compilation speed than the previous versions, in addition to producing higher-quality machine code. Second, a new linear scan register allocator was developed for the client compiler which is unrelated to the graph-coloring register allocator in the server compiler. You can find some more information about the new register allocator here and here.
sorry … i guess i am a master in spreading misinformation.
Java 6 has EA?
I thought it was pushed back onto Dolphin?
It has EA but it currently does not actually stack-allocate objects. Well, last time I looked. No time to squeeze that in presumably. And besides they want to be able to show off something big in Java 7 don’t they 
Cas
To be honest I really did not expect such huge wins for java-6 with the server-compiler, taking into account that all the “exciting” stuff was pushed back to dolphin.
I am really excited when we’ll see:
- Stack based allocation
- Tired compilation
- JIT code cache (theres a JCP which speaks about bundling pre-compiled code ~-> quite like a JIT cache)
lg Clemens
All the real fun happened on the client.
Cas
hopefully they’ll manage to get SIMD’s support in dolphin too.
…Structs!
* blahblahblahh ducks and runs for cover
Java 6 has EA to avoid deadlocks of threads i think, not for stack based allocation. Java 7 already has two teired compilation! Already some things to boast about…
But it seems like dolphin branched from mustang around b50ish, so alot of the bug fixes aren’t in (like java_impl.exe cmd line thing that pops up). I wonder how they are going to combine the two…
DP
It’s funny that you should mention bugs. Some change in Java 6 causes the bug in http://www.java-gaming.org/forums/index.php?topic=15410.msg122714 . I experience the same thing in Windows, though not with the same code the guy posted in the bug report. It does however occur with some code I wrote.
I encountered a game-breaking bug with some other version several years ago. I believe it was 1.4.2_02. I didn’t find out about the workaround until I bought Developing Games in Java.
Even so, the problem I’m having is a relatively minor one. For the rest of my current project, I’ll just use 1.5.0 update 10. After it’s done, I’ll try to create a workaround if the good people at Sun haven’t fixed it by then.
I just wanted to point out that Java 6 isn’t perfect. It’s alot better than having to use C++ and an endless supply of 3rd party libaries though!
Software is never perfect - but it can be really good!
lg Clemens
Indeed. I guess that this edition we have now really pwns…
Now only to get users to download it…
Btw…since now jvm is opensourced, are there gonna be some “lighter” implementations? I mean flash player is kinda weightless compared to jre…maybe not a place to discuss here…
[…]are there gonna be some “lighter” implementations?
Yes, you can then bundle some stripped down (private) JRE with your application. If you avoid swing/awt (~if you use lwjgl heh), the overhead will be pretty small. With lzma/p200 voodoo it’s only around 1.5-2.0mb* (depends on how much you actually need).
[* The latest flash installer is 1.4mb.]
A tiny lwjgl game fits nicely into 2.5mb for example and with a total size of 5mb you have lots of room.