The OpenJDK JVM eats class bytecode and spits out Java heap objects and machine code as part of normal execution. However, the JVM manages more data than just bytecode, Java objects JITted code. In order to manage heap memory and to ensure correct execution, the JVM and JITted code need to retain and, occasionally, interrogate details of the loaded class base. Bytecode is not a very 'efficient' representation for this purpose, nor does it include details of runtime-derived info like class and method implementation dependencies, compile history and JITted code status, or execution profiles.

So, the JVM throws away most bytecode after parsing, in its place constructing and maintaining its own 'efficient' in-memory (C++) data structures which model both the loaded class and method base and runtime-derived state. This is what is known as Class Metadata. Class Metadata is a significant component of the Native Memory storage allocated and managed by the JVM, alongside JIT Compiler Metadata, GC Metadata, Thread Metadata, etc. For small applications that don't create a large number of Java objects Metadata can constitute a large portion of a Java application's resident memory set.

This talk will begin by describing how to use the jcmd tool to measure summary JVM Native Memory storage costs, including overall Class Metadata costs. It will also show how to use jcmd to obtain a detailed breakdown of the latter costs, splitting the overheads along two axes: firstly, by class; and secondly, dividing per-class costs into separate sub-costs associated with different component subsets of the class model: classes per se, constant pools, methods and annotations.

I will go on to explain how Class Metadata is carved out of the memory regions managed by the JVM's Native Memory allocation routines and detail the memory layout of the various C++ types which define the elements of the Class Metadata model, thereby clarifying some of the more detailed statistics available in jcmd output. Real-life use cases will be employed to explain how specific costs arise from code design choices and to suggest how alternative choices might increase or decrease Class Metadata costs.