1. Overview

In this quick tutorial, we're going to get familiar with a few different ways to get the heap size of a running Java application.

2. jcmd

To find the heap and metaspace related info of a running Java application, we can use the jcmd command-line utility:

jcmd  GC.heap_info

First, let's find the process id of a particular Java application using the jps command:

$ jps -l
73170 org.jetbrains.idea.maven.server.RemoteMavenServer36
4309  quarkus.jar
12070 sun.tools.jps.Jps

As shown above, the process id for our Quarkus application is 4309. Now that we have the process id, let's see the heap info:

$ jcmd 4309 GC.heap_info
4309:
 garbage-first heap   total 206848K, used 43061K
  region size 1024K, 43 young (44032K), 3 survivors (3072K)
 Metaspace       used 12983K, capacity 13724K, committed 13824K, reserved 1060864K
  class space    used 1599K, capacity 1740K, committed 1792K, reserved 1048576K

This app is using the G1 or garbage-first GC algorithm:

  • The first line reports the current heap size as 202 MB (206848 K) – also, 42 MB (43061 K) is being used
  • G1 regions are 1 MB, there are 43 regions marked as young, and 3 as survivors space
  • The current capacity of the metaspace is around 13.5 MB (13724 K). From that 13.5 MB, around 12.5 MB (12983 K) is used. Also, we can have up to 1 GB of metaspace (1048576 K). Moreover, 13842 KB guaranteed to be available for use by the Java virtual machine, also known as committed memory
  • The last line shows how much of the metaspace is used to store class information

This output may change depending on the GC algorithm. For instance, if we run the same Quarkus app with ZGC via “-XX:+UnlockExperimentalVMOptions -XX:+UseZGC”:

ZHeap           used 28M, capacity 200M, max capacity 1024M
Metaspace       used 21031K, capacity 21241K, committed 21504K, reserved 22528K

As shown above, we're using 28 MB of the heap and around 20 MB of metaspace. As of this writing, Intellij IDEA is still using the CMS GC with the following heap info:

par new generation   total 613440K, used 114299K
  eden space 545344K,  18% used
  from space 68096K,  16% used
  to   space 68096K,   0% used
 concurrent mark-sweep generation total 1415616K, used 213479K
 Metaspace       used 423107K, capacity 439976K, committed 440416K, reserved 1429504K
  class space    used 55889K, capacity 62488K, committed 62616K, reserved 1048576K

We can spot the classic generational nature of the CMS GC in the heap configuration.

3. jstat

In addition to jcmd, we can use jstat to find out the same information from running applications. For instance, we can use jstat -gc to see heap statistics:

$ jstat -gc 4309
S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     
0.0    0.0    0.0    0.0   129024.0  5120.0   75776.0    10134.6   20864.0
MU      CCSC   CCSU     YGC     YGCT    FGC    FGCT     CGC    CGCT     GCTGCT
19946.2 2688.0 2355.0    2      0.007    1      0.020    0     0.000     0.027

Each column represents the memory capacity or utilization of a specific memory area:

  • S0C — The capacity for the first survivor space
  • S1C — The capacity for the second survivor space
  • S0U — The used space of the first survivor
  • S1U — The used space of the second survivor
  • EC — Eden space capacity
  • EU — Used space from Eden
  • OC — Old generation capacity
  • OU — Used space from Old generation
  • MC — Metaspace capacity
  • MU — Used space from Metaspace
  • CCSC — Compressed class space capacity
  • CCSU — Used space for compressed classes
  • YGC — The number of minor GCs
  • YGCT — The time spent for minor GCs
  • FGC — The number of full GCs
  • FGCT — The time spent for full GCs
  • CGC — The number of concurrent GCs
  • CGCT — Time spent on concurrent GCs
  • GCT — The time spent for all GCs

There are other memory-related options for jstat such as:

  • The -gccapacity to report different capacities for different memory regions
  • The -gcutil only shows the utilization percentage of each region
  • The -gccause is the same as -gcutil but adds the cause of the last GC and possibly current GC events

4. Command-Line Args

If we run a Java application with heap configuration options (for example, -Xms and -Xmx), then there a few other tricks to find the specified values.

For instance, here's how jps reports those values:

$ jps -lv
4309 quarkus.jar -Xms200m -Xmx1g

With this approach, we can only find these static values. So, there is no way to know about, say, the current committed memory.

In addition to jps, a few other tools will report the same thing. For example, the “jcmd <pid> VM.command_line” will also report these details:

$ jcmd 4309 VM.command_line
4309:
VM Arguments:
jvm_args: -Xms200m -Xmx1g
java_command: quarkus.jar
java_class_path (initial): quarkus.jar
Launcher Type: SUN_STANDARD

Also, on most Unix-based systems we can use ps from the procps package:

$ ps -ef | grep quarkus
... java -Xms200m -Xmx1g -jar quarkus.jar

Finally, on Linux, we can use the /proc virtual filesystem and its pid-files:

$ cat /proc/4309/cmdline
java -Xms200m -Xmx1g -jar quarkus.jar

The cmdline file, in a directory named after the Quarkus pid, contains the command-line entry for the application.

5. Conclusion

In this quick tutorial, we saw a few different ways to get the heap size of a running Java application.

Java bottom

I just announced the new Learn Spring course, focused on the fundamentals of Spring 5 and Spring Boot 2:

>> CHECK OUT THE COURSE
Comments are closed on this article!