So I use System.gc() manually, is it really that bad ?

[nsigma]

@princec

@nsigma

Same reason it has any impact on anything else - it stops the world! Not knowing quite what you mean by IO design practice, the audio libs in Praxis (which I’m finally in the process of getting out separately), in fact Praxis as a whole, is written around lock-free processing. This is the only way of doing decent low latency audio, but it doesn’t mean the GC can’t get in the way.

Hm does stop-the-world actually stop all threads in the process, or just all Java threads, or just block allocs in Java threads? We use OpenAL to do our actual audio mixing, which carries on regardless of GC occurring or not (it has its own “native” mixing thread).

Cas

I don’t know a huge amount about OpenAL, but I believe all the mixing and DSP (is there any DSP?) is done in native code? I’m talking about doing DSP and mixing in Java. I’ve got both a low-latency JavaSound server (possible if you ignore the way most people use JS!) and my own binding to Jack (JNA based so some potential for further optimisation). Jack uses a callback into the JVM, so even though the Jack thread is allocated outside the JVM, and has real-time priority, once it calls into the JVM it can still get into conflict with the garbage collector.

[lhkbob]

I remember reading somewhere that System.gc() does a stop-the-world collection if the JVM decides to respond to the GC request, even if you have a more parallel collector configured. Or it might be that if you’re using the default generational, mark-and-sweep collector, calling System.gc() is equivalent to doing a full collection which is stop-the-world.

I wouldn’t recommend using it since the JVM has a property you can set to disable the method call:"-XX:-DisableExplicitGC". They wouldn’t have that without a reason.

[nsigma]

@lhkbob

I remember reading somewhere that System.gc() does a stop-the-world collection if the JVM decides to respond to the GC request, even if you have a more parallel collector configured. Or it might be that if you’re using the default generational, mark-and-sweep collector, calling System.gc() is equivalent to doing a full collection which is stop-the-world.

I wouldn’t recommend using it since the JVM has a property you can set to disable the method call:"-XX:-DisableExplicitGC". They wouldn’t have that without a reason.

As far as I’m aware, all the GC’s have their stop-the-world moments (ie. they suspend all non-GC threads in the VM), so at some point the mark-and-sweep collector is still going to stop things - just hopefully for a much shorter time!