本机 memory 消耗的 JVM vs java 进程总 ZCD69B4957F06CD818D7BF3DD618

Question

I have a tiny java console application which I would like to optimize in terms of memory usage. It is being run with Xmx set to only 64MB. The overall memory usage of the process according to different monitoring tools (htop, ps, pmap, Dynatrace) shows values above 250MB. I run it mostly on Ubuntu 18 (tested on other OS-es as well).

I've used -XX:NativeMemoryTracking java param and Native Memory Tracking with jcmd to find out why so much more memory is used outside of the heap.

The values displayed by NMT when summarized were more or less the same as the ones shown by htop as Resident Memory.

NMT :

Total: reserved=1518873KB, committed=255877KB

htop :

I've used several JVM parameters to reduce native memory consumption (reduced stack size, changed GC to serial, Class Data Sharing etc). Both reserved and committed memory metrics went down according to NMT (both malloced and mmaped) by let's say ~50MB in total.

NMT :

Total: reserved=1475110KB, committed=209218KB

All the tools that I'm using (htop, ps, pmap, Dynatrace) show no difference at all. Total memory used by the process is still 250MB.

1. The question is, why is that? Why reducing native memory usage by JVM does not make any effect on the resident memory used by the java process? Is it reserved somehow upfront and not released?
2. Is there any other way to effectively reduce memory consumption by the whole java process (outside of the heap which is already optimized and set to only 64MB)?

Answer 1

NativeMemoryTracking may report less committed memory than the actual Resident Set Size (RSS) of a process for multiple reasons.

• NMT counts only certain JVM structures. It does not count memory mapped files (including loaded.jar files), nor memory allocated by libraries other than libjvm . Even native memory allocated by the standard class library (ie libjava ) is not shown in NMT report.

• When something allocates memory with a standard system allocator ( malloc ) and then releases it, this memory isn't always returned back to the OS. The system allocator may keep released memory in a pool for future reuse, but from the OS perspective this memory is considered used (and thus included in RSS).

This answer and this video may give an idea what else takes memory, and how to analyze footprint of a Java process.

This post describes some ideas (both reasonable and extreme) on reducing footprint.

Answer 2

• first, A typical memory representation of C program consists of following sections. ( https://www.geeksforgeeks.org/memory-layout-of-c-program/ )

  A typical memory representation of C program consists of following sections.

  1. Text segment
  2. Initialized data segment
  3. Uninitialized data segment
  4. Stack
  5. Heap

• JVM memory includes: JVM heap, JVM Stack, JVM native stack, The pc Register, and so on.

( https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5 )

• -Xmx means the maxium heap size of JVM, not the Java Process ， ( https://java.sun.com/javase/technologies/hotspot/vmoptions.jsp )

and the JVM heap just a part of Java Heap section (in c program memory representation).