G1 pauses and number of application threads

[Stefan Johansson]

Hi Nicola,

See my comments below.

On 2017-10-11 18:49, Nicola Ferraro wrote:
> Hi,
> I've started to look at G1 garbage collector internals and I would 
> like to know if the performance of G1 are affected by the number of 
> threads in the application. Doing a STW means stopping all application 
> threads, and this suggests me that the more threads you have in your 
> application, the longer STW pauses will be.
>
> I've done some basic tests (from 1 thread to 10, 100, 1000) and I'm 
> not able to see a clear pattern. But this may be due to my ignorance 
> on the topic. I'm collecting data using 
> "-XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics 
> -XX:PrintSafepointStatisticsCount=1" on JDK 8.

So this is true in the sense that all your application threads have to 
be stopped before the STW work can be started. The time it takes to get 
the threads stopped is not only connected to the number of threads. 
Having more threads might very well take a bit longer to stop, but what 
the threads are doing is also a factor. So you should not really expect 
to find a clear pattern here that you can apply to all applications.

>
> Is it true that the number of threads slow down G1 GC?

Not really, as you know the application threads are stopped during the 
STW pauses, so the number of application threads don't really affect G1 
that much while doing most of the GC work. One way the application 
threads do affect the GC pause (true for all GCs, most of this is) is 
that each thread generates some work since the GC need to ensure that 
objects used by the thread are kept alive. But once that is done the GC 
runs without being affected by the application threads.

Another way the application threads affect the GC is during the 
concurrent phase, where G1 mark through the Old regions in the heap 
without stopping the application threads. We usually see it as the GC 
affecting the application threads and not the other way around. In a 
scenario where a lot of application threads are running the GC threads 
will get less CPU time to do its work, and in that sense run slower.

Hope this helps,

Cheers,
Stefan

>
> Regards,
> Nicola Ferraro
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20171012/c631b410/attachment.html>