Garbage collector tuning

[Gudradain]

Seriously, I find it really strange that you get the best performance with G1 cas since that collector was designed to work with server like application using a huge amount of memory and running on multiprocessor machines.

How can that description fit a small game running on a single processor machine? For big desktop game it might be the good choice though

[Riven]

You confuse throughput with latency.

This.

[princec]

Thank you Riven.

Cas

Games published by our own members! Check 'em out!

[ags1]

I wonder how much difference these abstruse considerations make in the end. Just make the game, don't do anything too daft along the way, stick to what works, if it is too slow, find the slow code and fix it. Next game.

[Riven]

I wonder how much difference these abstruse considerations make in the end. Just make the game, don't do anything too daft along the way, stick to what works, if it is too slow, find the slow code and fix it. Next game.

I'm reasonably sure that's exactly what cas did, and ended up writing object pooling for specific cases.

I did the same, in a particle engine with both short and long living particles (each particle had a Matrix4f instance, and other shit, really heavy stuff).

[princec]

That's exactly what I did... I wrote what I wrote, then profiled it, tuned the bits that were causing unacceptable problems, and then tweaked the VM options a bit too. And here we are.

Cas

[Gudradain]

Ok ok -_-

I guess I should restate my statement since I was wrong... I did a new benchmark with thread pooling this time. Thread are usually long lived object so they are copied back and forth by the copying collector in the young generation if you don't use thread pooling. That create some heavy burden on the GC and it garbages a lot more. Also, creating a thread and starting it take some time, so it decreases performance too. So object pooling can be useful

New statement : Don't use object pooling for young objects.

In my first benchmark, I got better result because all objects died as soon as you exited the method. All those objects were easy to garbage by the copying collector since it could just ignore them all and copy only the objects currently alive (which was nearly nothing). Also, the object pooling in that example created a lot of reference from old to young objects which is bad.

On the other hand, in the thread pool benchmark, the thread lived a long time so they were copied back in forth by the copying collector.

In regard to that, using object pooling for particle engine is probably a good idea too because the life of the particles are not so short and so they will be copied back and forth by the copying collector, fill up the young memory space and the GC will do collection a lot.

One thing to note; if you use the wrong size for your object pool you will end up with bad performance (at least for thread). So be careful about the size of your object pool.

[sproingie]

Also, creating a thread and starting it take some time, so it decreases performance too. So object pooling can be useful

I presume you meant thread pooling.  Threads, filehandles, and DB connections are definitely expensive resources that should always be pooled unless you have a really compelling reason not to.  For threads, best advice I can give is don't mess with threads directly.  There's a rich set of concurrency stuff in java.util.concurrent, and even more if you branch out to third-party things like Kilim, Finagle, and Akka.

[Roquen]

Since there's somewhere between 600-700 GC related tuneable sets...GC tweaking is a good candidate for a wiki page.  For instance it seems like using NUMA could be interesting for multithreaded games.