Menu
With JRockit, you can get the full list of threads by any means, and all of these means include information about the Garbage Collection Thread(s):
1) Asking the Thread class for the information:
Thread.getAllStackTraces();
2) Using ThreadGroup to get that information:
ThreadGroup root = Thread.currentThread().getThreadGroup();
while (root.getParent() != null) {
root = root.getParent();
}
Thread[] list = new Thread[root.activeCount() + 5];
root.enumerate(list, true);
3) Using JMX to get the list:
ThreadMXBean THREAD_MX_BEAN = ManagementFactory.getThreadMXBean();
long[] tids = THREAD_MX_BEAN.getAllThreadIds();
ThreadInfo[] tinfos = THREAD_MX_BEAN.getThreadInfo(tids);
4) CTRL-BREAK
However, using the Sun JVM -- at least recent Java 6 releases -- only CTRL-BREAK seems to include the Garbage Collection threads and the VM Periodic Task thread. I find it useful to monitor CPU used by the GC threads so my application can detect and log when GC is using most of the CPU time. Without this information, you only know when GC exceeds certain set thresholds.
If I can even just find out the Thread ID of the GC threads, then JMX will probably give the rest of the information I need (unless there is something different about these Threads). For example, using the method:
long threadId = tids[0];
long cpuTime = THREAD_MX_BEAN.getThreadCpuTime(threadId);
Does anyone know how -- or if it is known to be not possible -- to get information about the garbage collection Thread(s) using the Sun JVM?
244
At a certain point in time, an event happens that triggers garbage collection. To clear the memory, application threads have to be stopped. This is where the work of your application stops and the next steps start. The garbage collector marks objects that are no longer used and reclaims the memory.
At this stage, we will focus on the tried and tested G1 GC which is available in Java 8, as well as Java 11 (Supported JDK for most ForgeRock applications).
Thus, with each garbage collection, G1 continuously works to reduce fragmentation. This is beyond the capability of both of the previous methods. CMS (Concurrent Mark Sweep) garbage collection does not do compaction. Parallel compaction performs only whole-heap compaction, which results in considerable pause times.
To modify the number of threads, use the flag-XX:ParallelGCThreads=#, where # is the number of threads (in our case, eight). Once you've enabled those flags, test the application and see how much performance you've gained. Ideally, your application should now run faster and have shorter GC pause times.
This is specific to the Java 1.5+ Sun (HotSpot) JVM. Register the MBean sun.management.HotspotInternal in the MBeanServer you are looking to monitor from. This will trigger the registration of these HotSpot internal mbeans:
The HotspotThreading MBean has an attribute called InternalThreadCpuTimes which is a map of HotSpot's internal threads.The GC threads are identifiable by name. For example, in the JVM I am running right now, they are called:
The value of the map is the CPU time for each thread.
The HotSpotMemory MBean also has an attribute called InternalMemoryCounters which has a few additional bits of information about GC.
197
A first step is to use verbosegc:
java -verbose:gc -XX:+PrintGCDetails, which will give you some information about (wall clock) time consumed in GC operations, and the type of operation (full or incremental). Your question seems to be asking whether you can get it programmatically -- probably can get some info via the management I/F.
Edited to add: Some of this is available via the MemoryMXBean, but not the specifics of GC time. Sorry...
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
