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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
