What is contained in code/internal sections of JCMD?

Question

Dimensioning a docker container for a JVM based service is tricky (as we all know). I'm pretty sure we have slightly under-dimensioned a container and want to clear up a few questions I have relating to specific jcmd (Native Memory Tracker) outputs that we see when monitoring.

Questions:

• Are Direct Byte Buffers included in "Internal" as reported by jcmd?
• What else apart from code cache is in "Code" as reported by jcmd?
• Is there a good way to limit the "Code" section as reported by jcmd. I read https://docs.oracle.com/javase/8/embedded/develop-apps-platforms/codecache.htm but this only covers the code cache limits and it is suggested to leave the JVM default as is.

JCMD output is here.

Direct Byte Buffers JMX properties are here.

Some background details:

The Setup:

• Spring boot based application

• JVM Options:

  -server -Xms1792m -Xmx1792m -XX:MetaspaceSize=128M - XX:MaxMetaspaceSize=192M -XX:+UseG1GC -XX:+UseStringDeduplication - XX:MaxDirectMemorySize=256m -XX:NativeMemoryTracking=detail

• Docker container 2500MiB running in AWS/EC2

Beside

Answer 1

Are Direct Byte Buffers included in "Internal" as reported by jcmd?

(updated) ByteBuffer.allocateDirect internally calls Unsafe.allocateMemory which is counted by NMT in the Internal section (denoted by mtInternal constant).

On the contrary, MappedByteBuffers (obtained by FileChannel.map) are not reflected in NMT report, though they definitely may affect the amount of memory used by the process from OS perspective.

What else apart from code cache is in "Code" as reported by jcmd?

Auxiliary VM structures for maintaining compiled code and generated runtime stubs: hashtables, code strings, adapter fingerprints etc. They all are rather small comparing to the CodeCache itself. These structures make up 'malloc' part in the report while the CodeCache goes into 'mmap' part.

Is there a good way to limit the "Code" section as reported by jcmd.

Turning off tiered compilation (-XX:-TieredCompilation) is likely to reduce the amount of memory used by "Code", just because there will be a lot less generated code. But make sure you understand what tiered compilation is and what performance impact it may have.

Bedraggle

I'm pretty sure Direct Byte Buffers are in "Internal". I asked as I don't see this documented anywhere officially and hoped someone could point me to something official. From my own testing I'm pretty sure they are. Also this gist gist.github.com/prasanthj/48e7063cac88eb396bc9961fb3149b58 shows they are indeed accounted for there. – Beside

@RonanB Sorry for confusing you - I was thinking about MappedByteBuffers. Memory allocated by ByteBuffer.allocateDirect indeed goes to "Internal" section of NMT report. I updated the answer with the links to relevant JVM sources. – Bedraggle