CMS and other collectors (instead of G1) use TraceMemoryManagerStats to post statistics at every STW pause.
G1 uses the TraceMemoryManagerStats during a non-marking related pause.
From mail thread:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019251.html
I looked a bit through the source to see where and how the various collectors use TraceMemoryManagerStats, and actually it seems to me the reason that G1 can run this test with ExplicitGCInvokesConcurrent is that unlike the other collectors it really only uses the TraceMemoryManagerStats during a non-marking related pause, while the others (particularly CMS) post these statistics at every STW pause. I can imagine that this means that GC statistics for all tools that use these do not get any relevant notifications with G1 for marking related STW pauses (remark, cleanup).
This seems to be something that may need to be fixed.
G1 uses the TraceMemoryManagerStats during a non-marking related pause.
From mail thread:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-November/019251.html
I looked a bit through the source to see where and how the various collectors use TraceMemoryManagerStats, and actually it seems to me the reason that G1 can run this test with ExplicitGCInvokesConcurrent is that unlike the other collectors it really only uses the TraceMemoryManagerStats during a non-marking related pause, while the others (particularly CMS) post these statistics at every STW pause. I can imagine that this means that GC statistics for all tools that use these do not get any relevant notifications with G1 for marking related STW pauses (remark, cleanup).
This seems to be something that may need to be fixed.
- relates to
-
JDK-8165955 TestFullGCCount test failed with CMS and -XX:+ExplicitGCInvokesConcurrent
-
- Resolved
-