//Garbage First - It has never been so exciting to collect garbage :)

If you are reading this entry, you probably already know about G1 the new Garbage First concurrent collector currently in development for Java 7.

Jon Masamitsu made recently a great overview of all GCs currently integrated into JVM of Java SE 6 and announces the new G1 collector on his weblog.

I asked him in the comments some questions about G1 and a very interesting discussion starts. Tony Printezis an expert from the HotSpot GC Group joined the discussion and answered all the questions very detailed.

(I have aggregated the discussion here because I think it is much easier to read if the answer follows next to the question without the noise between them)

me: I just recently thought about stack allocation for special kind of objects. Couldn't the hotspot compiler provide enough information to determine points in code when its safe to delete certain objects? For example many methods use temporary objects. Is it really worth to put them into the young generation?

Tony: Regarding stack allocation. I believe (and I've seen data on papers that support this) that stack allocation can pay off for GCs that (a) do not compact or (b) are not generational (or both, of course).

In the case of (a), a non-compacting GC has an inherently slower allocation mechanism (e.g., free-list look-ups) than a compacting GC (e.g., "bump-the-pointer"). So, stack allocation can allow some objects to be allocated and reclaimed more cheaply (and, maybe, reduce fragmentation given that you cut down on the number of objects allocated / de-allocated from the free lists).

In the case of (b), typically objects that are stack allocated would also be short-lived (not always, but I'd guess this holds for the majority). So, effectively, you add the equivalent of a young generation to a non-generational GC.

For generational GCs, results show that stack allocation might not pay off that much, given that compaction (I assume that most generational GCs would compact the young generation through copying) allows generational GCs to allocate and reclaim short-lived objects very cheaply. And, given that escape analysis (which is the mechanism that statically discovers which objects do not "escape" a thread and hence can be safely stack allocated as no other thread will access them) might only prove that a small proportion of objects allocated by the application can be safely stack allocated (so, the benefit would be quite small overall).

(BTW, your 3D engine in Java shots on your blog look really cool!)

thank you! :)

[Read More]

//Java 3D is dead (again). Long live Java 3D! ;-)

It was like a deja-vu for me as I read this announcement about the future plans of the Java 3D scenegraph API. It is already the second time the development of Java 3D has been set to 'maintenance mode' and stopped for any further improvements.

But this time it is not bad at all. Why?

"Specifically, we are working on a new 3D scene graph, as part of the JavaFX player, that will complement the 2D Scenario scene graph. Its initial focus will be 3D effects, casual games, and simple 3D viewing applications..."

OK. But what about projects like Wonderland which use Java 3D and are no "simple 3D viewing applications"?

It is getting even better: Project Wonderland announces the complete move to the JMonkeyEngine!

"As part of our recent review of Wonderland, which resulted in the API
cleanup tasks that are now underway, we also took a long look at our
graphics subsystem. Our main goal here was to ensure we could create a
very rich 3D experience. We also reviewed the tool chain for creating and importing
content into Wonderland. After careful consideration by the Wonderland
team, and discussion with the Java 3D team we have decided that
Wonderland will be best served by moving to the JMonkeyEngine scene
graph API... "

Now it is getting very interesting. Wonderland was always in my opinion a far to advanced project to be limited to the visual and design constrains of Java 3D (watch the videos!). The JMonkeyEngine is a full featured 3D (game) engine already used by professional game companies (NCsoft...).

Still not happy?

then be patient and wait for Java 3D 1.5.2 (maintenance release) which will be relicensed to a dual GPLv2 + CP ex license.

//Java SE 6 Update N Early Access build 10 available + new FAQ and release dates

a new ea build of Java 6 Update N is available with a lot of bugfixes, ready for testing

my favorite fixes:
6641571RFE Enable new plug-in as default in 6u10 b10
6524352 Defect support for high-resolution mouse wheel
this was actually a particulary annoying one :)

release schedule (on top) + download link (bottom).

New Java Kernel FAQ (interesting!)

//Pictures of my old 3D Engine in Java

Here are some screenshots of my 3D Engine (codename Metaverse) I made a few years ago (click to enlarge). It is written in Java and uses JOGL (JSR 231) as OpenGL binding and JInput to access the controllers.

These shots show the real time lighting and water rendering capabilities. They also show that you are the whole time on a real 3D planet (codename potato ;) ).

The next shows a 'test vehicle' to test model loading, animation, physics and collision detection of the Engine. You can use this vehicle to discover the planet - it makes even a lot of fun to drive through rough terrain and try to survive jumps from steep hills ;). The other screenshot shows the planet as wireframe.

The last two show the continuous triangulation of the terrain mesh and the space subdivision into a quad-tree (important for fast frustum culling and physics). The viewer is configured to be located inside the river bed.

You think that Java for 3D Graphics is like a penguin in hell? If you follow some rules to prevent stop the world garbage collections (full GCs) and prevent calls through the JNI where possible you can reach with the server (hotspot compiler) JVM performance comparable to C++ code.

The rendering performance is quite good. Even fast fly overs are rendered with 60+ fps (frames per second). If the camera stays still the renderer reaches 200+ fps on my notebook (ATI X1600) .

I have currently no time to continue with this project but if I think back how fun it was to work on that engine I would love to start hacking again immediately ;).

//NetBeans OpenGL Pack is evolving

The NetBeans OpenGL Pack is slowly evolving to a set of useful integrated tools, demo applications and editors for Java OpenGL development.

The features currently included are:

  • Editor for the OpenGL Shading Language (GLSL) with compiler error annotation, code folding, syntax highlighting, auto completion and documentation.
  • Easy access to the GLSL compiler and linker of your graphics driver integrated in the editor
  • OpenGL Capabilities Viewer
  • Integration of JOGL GUI components into the Matisse GUI builder
  • JOGL project templates
  • Ready to run JOGL demos and examples of the OpenGL Programming Guide (also known as Red Book) 

We are currently fixing the last bugs and hope to build the first release soon. The early access version is available via Update Center in the download section of the project page.

The project has also been recently mentioned in the NetBeans Magazine [issue four] covering NetBeans 6 features. Geertjan Wielenga interviewed me about the GLSL editor in the Schliemann section of the magazine.