If I read that article correctly, no matter what happens there is ALWAYS a stop-the-world phase during garbage collection.... and it ALWAYS seems to take a huge amount of time.

If this is true,

For the gaming community what can we do to minimize this impact? Any thoughts? And no, I don't mean simply just using -Xincgc, I figure that's the first thing we try.... I mean more aggressive techniques.

For the gaming community what can we do to minimize this impact? Any thoughts?

Yes, we can. We have to write games that are appropriate for Java. And maybe these are not maximum-framerate games running in a tight loop.

Make your gameloop do whats needed - and then go to sleep(). Give the JVM some time to breath.

Thats also the way Java3D is meant to operate.

To my experience a Java program will never run smoothly if you overcommit the primary gamethread. Even Java3D apps can run smoothly if not WakeupOnElapsedFrames(0) but WakeupOnElapsedTime( aGoodValue ) is used to drive the game.

In my prototype, I have an FPS slider. If you put it to 30, everything is smooth, if you goto 80, you experience teh stop-the-world phase!

Or alternatively just sit back while swapBuffers puts your thread to sleep for you in GL

And don't be allocating any objects in your rendering loop.

Create them all at game init and level init, and recycle them. It's nearly guaranteed to get rid of the pauses but at the expense of a little complexity. But the C/C++ crowd have been doing this for years because malloc and new are so inefficient.

I run an old dual p2/333 at home and I must say the new concurrent collector does wonders. I have been able to almost totally eliminate any gc pauses. Every once in a while you notice a slight hitch when it does a full pass but other than that it is very smooth. I have read in a couple places that 1.4.2 and 1.5 will give us many more gc options so for the next few months I am going to be very optimistic.

In my (extremely limited) experienced writing some timing-critical drawing routines, I've found that the best way i've managed to eliminate garbage collection is to create state-objects that are created once and maintain the state of things for various operations, and also have 'init' methods on them when I need to reset them for another action...I donno if that makes sense, but basically the point is that instead of re-creating objects (that will be needing to be garbage collected later) I define objects that I can modify values of and reuse the memory instead of creating whole new objects again (I do this sort of thing with my line interator class (search the old forums) and it allowd me to traverse a series of points with no object creation.

With the single-threaded nature of most games, you won't need to worry about your state object being mucked with when you aren't looking (if you write in a single-threaded archietecture).

I think the number one rule in high performance game programming is zero garbage collection (if possible). Even if that means resorting to pooled objects that are placed in a pool and used and then put back into a pool (but the pool objects never go away) you don't tax the garbage collector...I wonder if the garbage collector is smart enough to realize that if there's no object creation since it's last sweep, it has no work to do.

Actually I assume you mean to give objects directly to the collector so it doesn't have to find them itself... the thing with that is that the collector must still verify that there are no references to the objects any more.. so it has to do all that 'finding' work anyway to prevent potential access to collected objects.

Getting an adaptive oct/quadtree to run in a tight loop is almost impossible, since there is no way to flag objects to be deleted in the next cycle.

Maybe this is a case where Object pooling would work?

Don't flag objects for deletion.. put them back in the pool to be recycled.

Depending on various factors, object pooling can pay off. But in general it is discouraged as it makes more long-lived objects for the collector. If you can keep all of your per-frame objects in the 'short-lived' ('nursery') part of the Java heap then maybe you can get away with a few 'new's per frame.

As palmer said it won't work, however I don't know enough about the GC to discuss about this matter

I'm currently running with pooling. It is not the most elegant way to do it, but more a cheap alternative that eventually costs more than the more expensive route. However, pooling *is* more more expensive than doing non adaptive map, where the initial point of adaptivity gets trashed. So basically a static quadtree is just better.

Adaptive lod on the otherhand is not a problem the way I see it. As long as i'n using simple types, such as floats, there won't be a big hit in performance, since if I have 600 nodes with 7 sub divisions that will be only few hundred new objects and actually I'm not even newing the object, just changing the content.

AFAIK you shouldnt reallty care when thinsga re colelcted so long as you always have cheap memory available for you currentoperations.

if you are keeping objects referenced for only 1 frame at a time then again FWIK it should never escape the newsapce, where allocation and collkection are very cheap. (Arguably as cheap or cheaper then the work invovled in managing a pool.)

It is possible yo uare creating so many object thats you are thrashing the new space and causing object to prematurely progress to the next generatioon. There is an -XX falg for adjusting the size of the new space (and given time, HS will make adjustments on its own.)

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Another article, all about the garbage collectors available as of 1.4.2, and how to tune them to your bidding (at least as much as we can). Detailed examples of when to, and when not to use particular collectors, and good tips on how to optimize each collector for a specific task. The moral here? Work with the collector and don't assume right away that it is your enemy (though it may turn out to be so anyway).

This surely duplicates some information found in the article that started this whole thread.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org