I ripped a smaller test case out of a 3d demo to see if scalar replacement works. In my case it did an amazing job. Here's the link to my blog entry: http://www.stefankrause.net/wp/?p=64

I can confirm that JET is pretty fast. I published a benchmark four years ago where some JVMs were compared: http://www.stefankrause.net/wp/?p=9

For interactive applications I'd recommend to compare GC pause times as well. Last time I checked JET had significantly larger pause times than Oracle's Hotspot VM.

Cool list.

I'd like to add scalar replacement (since ~2008) which depends on escape analysis (see http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/). Found it amazingly effective in the context of typical 3d math (detail in my blog entry http://www.stefankrause.net/wp/?p=64).

I'd really like to see more articles testing the effectiveness and limitations of those optimizations (e.g. range check elimination, inlining).

As for devirtualization I found two nice articles:
http://www.javaspecialists.eu/archive/Issue157.html
http://www.javaspecialists.eu/archive/Issue158.html

Very cool - thanks. A debug VM used to be available for pre-release JDKs, but I don't find it anymore for JDK 8 or JDK 7u4. Do you build it yourself or is it still available for download?

Scalar replacement in the jvm is pretty cool, but my problem is that I don't know an easy way to check if and where it works. Does anyone have an idea how to check whether an allocation has been replaced?
So far the only way I found is to run a stress test for the method in question with "-verbose:gc" and see if the gc runs less often.
Any better ideas?

Thanks,
Stefan

Really? It was made public on 01/31 here:
http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

(and yes - it should never have been disclosed that way...)

Unless you use a simple for-loop (https://lampsvn.epfl.ch/trac/scala/ticket/1338 ). Must that good old for (int i=0;i<10;i++) really be deprecated?

And what strikes me most is that I'm afraid I'll never fully grasp the scala type system - take a look at http://apocalisp.wordpress.com/2010/06/08/type-level-programming-in-scala/
Maybe then the Gosu approach to accept an inconsistent type system isn't that bad as long as your team understands the restrictions (and java arrays definitely caused less trouble than java generics for the teams I've worked with)

I managed to migrate to JOGL2 (and killed all that fixed function pipeline stuff). It works, but I don't really understand what I'm doing. The only source I found so far is http://michael-bien.com/mbien/entry/jogl_2_opengl_profiles_explained .

Is there some information available:
* What's the packing strategy? What JARs, LIBs have to be or should be in the classpath? (There are quite a lot of them and some time ago the *.all.jar meant all but DebugGL etc.)
* What's nativewindow and newt? When would you use it? Is active rendering the preferred way to render then? What's the event threading model used...

Thanks for any insights!

@sgoethel: Do you consider adding NV_vertex_buffer_unified_memory and NV_shader_buffer_load as well?
(Though I consider that doing so might be hard work, cause they don't fit the OpenGL 3.1 deprecation model well.)

Thanks - great to see JOGL2 is alive and kicking.

First let me say I'm very happy to see that JOGL has a future (even if quite an incompatible one...)

The current version of JOGL2 doesn't have support for EXT_DIRECT_STATE_ACCESS. Do you plan to add this extension?

How are you going to support OpenGL 3.1? Create a new interface (GL3_1) with the deprecated functions removed?

Yours,
Stefan

Now that OpenGL 3.1 is released and (beta) driver support is also already there from day one (nvidia even released a linux version!) I'm excited to see if JOGL and when lwjgl will support OpenGL 3.1 and how the removal/deprecation of functions shows up in the java api.

@gouessej: I think it hasn't been answered yet. Could you please tell us why not? (Would you suggest using active rendering instead?)

Can you please explain what limits JOGL imposes? I don't know any GL feature that LWJGL supports and JOGL does not (except GL3 of course). And I'm the greatest fan of DebugGL (and it's the object oriented approach that makes that decorator easily possible) - if I had had that with C++ it would have saved me much frustration. Is there something like that in LWJGL?

Another question: Do you LWJGL users really know to which GL revision or extension a specific function belongs (I don't) or do you have static import blocks that you simply copy each time?

It depends - from a OpenGL user's view it isn't, but from a OpenGL programmer's view it is.
Anyways JOGL's promise (at least my view of it) was to be the Sun endorsed OpenGL API. That's what I'm looking for (I was sick of all the short lived OpenGL extensions C++ wrappers), but if JOGL fails to support OpenGL 3 now (though as we've seen it shouldn't be too difficult - just a bunch of extensions and maybe some initialization stuff) then I lose confidence that JOGL will support the next revisions of OpenGL in time.

Thanks for your answers - at least the community seems to be alive ;-)

Good to see that there is a momentum for JOGL (even if it's seem to be focused on OpenGL ES), but still a bit disappointing that there seem to be no GL 3 features in the JOGL_2_SANDBOX branch.
I really hoped that the official binding would keep up with current versions. I think I'll switch to LWJGL, since I want to play with the GL_EXT_direct_state_access extension.

Now that nvidia offers official opengl 3.0 support and JOGL offers no opengl 3 support I start to wonder whether JOGL is actually as dead as it currently seems. Is there any hope that after JavaFX has been pushed out we'll see opengl 3.0 support and new nightly builds?

Can you tell more about that? Is there a -XX switch to adjust that limit? What options have to be set in the debug commandline  (Does -XX:PrintCompilation also show that effect)?

You could try to set the materials just once.
You're passing a java array to glTexCoordPointer (and I guess the same is true for all other glXPointer calls). You should see a much better performance when you switch to vertex buffer objects (VBO) with direct buffers instead.

I used that too, but in comparison to immutable types I think it's still too mutable. It works fine for types you create and return (which shouldn't be changed by clients), but it doesn't free you completely from making defensive copies and it doesn't make those objects threadsafe.

Does someone have facts under what conditions the c1 or c2 hotspot compilers are able to inline methods?

Ken, you were absolutely right. I took the Java GLUT code and ported it back to c and got different results:

Java (1st iteration)
FBO Texture Rendering FPS: 237.485172
Teapot Shader FPS: 164.152181
Frame overhead secs/frame: 0.000020
OS/GLUT overhead secs/frame: 0.000587
Overall FPS: 91.658273

Java (2nd iteration)
FBO Texture Rendering FPS: 240.625000
Teapot Shader FPS: 165.317919
Frame overhead secs/frame: 0.000024
OS/GLUT overhead secs/frame: 0.000356
Overall FPS: 94.478528

C
FBO Texture Rendering FPS: 244.326587
Teapot Shader FPS: 162.869442
Frame overhead secs/frame: 0.000023
OS/GLUT overhead secs/frame: 0.000012
Overall FPS: 97.392490

Actually these results are quite impressive! Although the code is creating incredibly many OpenGL calls it's very close to the C version.
It's just too strange that the teapot function made the difference - I even compared your GLUT version with some version found on google code. Apparently my installed version of GLUT uses a simpler method to render the teapot.

Did you check snippet #209 on http://www.eclipse.org/swt/snippets/ ?

Recently there was a small benchmark on http://graphcomp.com/opengl/bench.html
I thought that it might be fun do a quick conversion to java, but if I had known the results before I maybe wouldn't have.
The c version prints something like:

FBO Texture Rendering FPS: 239.646497
Teapot Shader FPS: 570.048602
Frame overhead secs/frame: 0.000044
OS/GLUT overhead secs/frame: 0.000011
Overall FPS: 167.167671

The JOGL (JOGL 1.1 rc 3, JDK 6) version returns:
FBO Texture Rendering FPS: 208.672087
Teapot Shader FPS: 153.128346
Frame overhead secs/frame: 0.000035
OS/GLUT overhead secs/frame: 0.000584
Overall FPS: 83.737661

Obviously using GLUT functions and using immediate mode isn't the best performing way of woking with OpenGL today, but I think the benchmark might have a purpose for showing the overhead on JNI. Is that expected that JNI adds that much overhead (I had expected something like 10-20% overhead)?
Would you have expected such a large difference?
If you want to run the benchmark or check my conversion (after all - maybe there's a bug somewhere) see the attached file.

Let me add two questions:
Is it just me who is waiting every week for the next JDK 7 build, hoping it'll come with tiered compilation?
Anyone tried the IBM 6 pre-release? It has a not yet documented but nonetheless mentioned feature called "Data sharing between JVMs: Ahead Of Time (AOT) compiled code" - sounds interesting...

I have a very strange problem when I render with JOGL on a SWT Shell both for the JOGL RI and your JOGL SWT lib (that I also posted on the swt newsgroup but without reply). When I try to use FBOs with SWT I'm getting a black screen on windows as soons as I bind the fbo and an occasional flickering on linux (both with current nvidia drivers). Using the same FBO code for rendering works fine with AWT. If I don't use FBO all rendering works perfectly for both AWT and SWT.
Do you have any idea what could cause that?  (Something like special caps for FBO or so?)

Yours,
Stefan

I actually consider removing the profiling functions once it's done ;-)

Currently I'm profiling the time per object and there are about 130 objects in the scene and thus 260 calls to System.nanoTime. 

System.nanoTime() is a great way to find performance problems when System.currentTimeMillis's resolution isn't sufficient.

But I had to discover the drawback of System.nanoTime when I compared the runtime of a benchmark on windows and linux.
To my surprise it turned out that windows took something like 1.23 msec and linux took 1.67 msec for the same algorithm (computing the silhouette of a 3d object) on the same jdk version(1.5.0_06). It turned out that actually the operating system doesn't influence the duration of the algorithm, but that System.nanoTime() is so much slower on linux than on windows!

Is this a known effect (Maybe this is a notebook specific effect due to CPU power saving)? I think it's particularly bad that the longer duration of System.nanoTime influences the measurement itself!

As a workaround: What high precision, low impact timer that runs on both windows and linux can you recommend (that also works on notebooks - where simple RTDSC based timers appear to fail)?

Yours,
Stefan

I'm not 100% sure, but I do think that the 9250 is feature-wise identical with the radeon 9000, wich is a DX8 class card lacking hardware support for GLSL and OpenGL 2.0. I think that you need at least a radeon 9500 to have GLSL / OpenGL 2.0 support.
Is there someone who knows exactly?

The opengl version depends on the driver you're using and the capablities of your card. What's your driver version, OS and your graphic card?