public class CheckHeapSize {

    public static void main(String[] args) {
        long heapSize = Runtime.getRuntime().totalMemory(); 

        // Get maximum size of heap in bytes. The heap cannot grow beyond this size.// Any attempt will result in an OutOfMemoryException.
        long heapMaxSize = Runtime.getRuntime().maxMemory();

         // Get amount of free memory within the heap in bytes. This size will increase // after garbage collection and decrease as new objects are created.
        long heapFreeSize = Runtime.getRuntime().freeMemory(); 
        
        System.out.println("heap size: " + formatSize(heapSize));
        System.out.println("heap max size: " + formatSize(heapMaxSize));
        System.out.println("heap free size: " + formatSize(heapFreeSize));
        
    }
    public static String formatSize(long v) {
        if (v < 1024) return v + " B";
        int z = (63 - Long.numberOfLeadingZeros(v)) / 10;
        return String.format("%.1f %sB", (double)v / (1L << (z*10)), " KMGTPE".charAt(z));
    }
}

maybe an useful update using Java 17 to 19: After several trials with getRuntime() and old/Eden/Survivor Space I came back to use getRuntime() which seem to be 'faithful' now:

With Java 17-19 therefore I propose to use the heap size functions of getRuntime():

Runtime env = Runtime.getRuntime();

System.out.println("Max Heap Size = maxMemory() = " + env.maxMemory()); //max heap size from -Xmx, i.e. is constant during runtime
System.out.println("Current Heap Size = totalMemory() = " +  env.totalMemory()); //currently assigned  heap
System.out.println("Available in Current Heap = freeMemory() = " + env.freeMemory()); //current heap will extend if no more freeMemory to a maximum of maxMemory
System.out.println("Currently Used Heap = " + (env.totalMemory()-env.freeMemory()) );
System.out.println("Unassigned Heap = " + (env.maxMemory()-env.totalMemory()));
System.out.println("Currently Totally Available Heap Space = "+ ((env.maxMemory()-env.totalMemory()) + env.freeMemory()) ); //available=unassigned + free

This command shows the configured heap sizes in bytes.

java -XX:+PrintFlagsFinal -version | grep HeapSize

It works on Amazon AMI on EC2 as well.

cd /opt/www/java/jdk/bin/

# jmap -heap <JAVA_PID>

For Java 8 you can use the following command line to get the heap space utilization in kB:

jstat -gc <PID> | tail -n 1 | awk '{split($0,a," "); sum=a[3]+a[4]+a[6]+a[8]; print sum}'

The command basically sums up:

• S0U: Survivor space 0 utilization (kB).
• S1U: Survivor space 1 utilization (kB).
• EU: Eden space utilization (kB).
• OU: Old space utilization (kB).

You may also want to include the metaspace and the compressed class space utilization. In this case you have to add a[10] and a[12] to the awk sum.

Note that the below answer might require JMX to be enabled - I believe it's disabled by default in public JRE, and requires a restart of the JVM to change it, which would be rather useless in your case. Still, worth a shot?

Whether they work or not will also depend on the specific native wrapping method used by this application.

You should be able to copy these tools along with jli.dll from a JDK with a matching minor version and architecture to the JRE you're running. You could also run the tools remotely, though that's less likely to work without some initial set up due to the security requirements for remote connections.

The jps tool, available in the JDK, should be able to provide this information with the command jps -v. If you have multiple Java processes running, you can identify them by the PID in the first column.

Example output on Netbeans (PID 9056) (which uses a native wrapper similar to your application):

9056  -Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade -Dnetbeans.accept_
license_class=org.netbeans.license.AcceptLicense -client -Xss2m -Xms32m -XX:Perm
Size=32m -Dapple.laf.useScreenMenuBar=true -Dapple.awt.graphics.UseQuartz=true -
Dsun.java2d.noddraw=true -Dsun.java2d.dpiaware=true -Dsun.zip.disableMemoryMappi
ng=true -Xmx1024m <snip>

Notice the -Xss, -Xms and -Xmx arguments.

Another thing you can try is jinfo, which allows you to target a specific PID, e.g. jinfo 9056.

NOTE - This utility is unsupported and may or may not be available in future versions of the JDK.

You could also try jconsole and jvisualvm, though they seem to have trouble attaching to wrapped JVMs and listing VM arguments, from my testing.