Data areas
Data areas describe memory regions managed by the JVM. Some are per-JVM instance, others are per-thread.
Per-thread
pc
register
Per-thread pc
(program counter) register, set to the address of the instruction being executed if not native
. Wide enough to accommodate a returnAddress
or native pointer.
Stack
Per-thread stack storing frames, doesn't need to be contiguous. May be a fixed size or dynamically extend and contract, and if a fixed size the size may differ between stacks.
JVM throws:
StackOverflowError
when computation in a thread requires a larger stack than is permitted.OutOfMemoryError
if dynamic expansion of a stack is attempted but fails due to insufficient memory.
-Xss
(and -XX:ThreadStackSize
) configures the stack size, in bytes.
Frames
Frames may be heap allocated and are used to:
- Store data and partial results.
- Perform dynamic linking.
- Handle return values for methods.
- Dispatch exceptions.
- Implementations may additionally extend frames with additional debugging information.
Local variable array and operand stack determined at compile-time and supplied alongside the code for the method associated with the frame.
Operand stack
The operand stack is used to prepare parameters to method calls and receive results. It is empty at frame creation time. Values are pushed to the top of the stack before invoking a JVM instruction which will pop the values, perform a computation, and push the result.
Dynamic linking
Frames facilitate dynamic linking by referencing symbols in the Run-time Constant Pool. References to as-yet-undefined symbols may be translated into storage locations for dynamic loading.
Native method stacks
Colloquially referred to as "C stacks", native method stacks are typically created per-thread. They're not required for a JVM implementation if not supporting native invocation.
JVM throws:
StackOverflowError
when computation in a thread requires a larger native stack than is permitted.OutOfMemoryError
if dynamic expansion of a native method stack is attempted but fails due to insufficient memory.
Heap
The heap is shared among all threads, and is garbage collected.
JVM throws OutOfMemoryError
if computation requires more heap than can be made available.
- Total heap:
-Xmx
(-XX:MaxHeapSize
) configures the maximum size of the memory allocation pool. By default, this is set to (where isMaxRAM
and isMaxRAMPercentage
).-Xms
sets both:-XX:InitialHeapSize
configures the initial size of the memory allocation pool.-XX:MinHeapSize
configures the minimum size of the memory allocation pool.
-XX:MaxHeapFreeRatio
sets the maximum permitted percentage of free heap space after a GC event, after which the heap should be shrunk. Defaults to 70%.-XX:MinHeapFreeRatio
sets the minimum permitted percentage of free heap space after a GC event (defaults to 40%).- Ergonomics heuristics:
-XX:MaxRAM
sets the maximum amount of RAM that can be used for the heap before applying ergonomics heuristics, defaulting to the smallest of the maximum amount of memory available to the JVM or 128GB.- Sets
-XX:-UseCompressedOops
by default, though this can be overridden.
- Sets
-XX:MinRAMPercentage=n
sets the minimum amount of memory used for the Java heap as a percentage of the maximum amount defined in-XX:MaxRAM
. Defaults to 50%, and applies to JVMs with <=125MB memory.-XX:InitialRAMPercentage=n
sets the initial amount of memory used for the Java heap as a percentage of the maximum amount defined in-XX:MaxRAM
. Defaults to 1.5625%.-XX:MaxRAMPercentage
sets the maximum amount of memory used for the Java heap as a percentage of-XX:MaxRAM
. Defaults to 25%, and applies to JVMs with >125MB memory.
- New generation:
-Xmn
sets both:-XX:NewSize
sets the initial sizes of the young generation. It's recommended to be between 25% and 50% of total heap size.-XX:MaxNewSize
sets the maximum size of the young generation, and is set ergonomically by default.
-XX:NewRatio
sets the ration between the young:old generation sizes. Defaults to 2 (e.g. 2:1).-XX:SurvivorRatio
controls the ratio between the eden:survivor spaces. Defaults to 8 (e.g. 1:8)
Metaspace
Shared among all threads, the metaspace contains per-class structures (Run-time Constant Pool, field and method data, constructor, symbols, and annotations) maintained by class loaders and derived from JVM bytecode.
Class metadata is deallocated when Java classes are unloaded as part of GC. When the committed space reaches a high watermark the JVM will induce a GC, following which the high watermark may be raised or lowered based on the amount of freed space.
Prior to SE 8, this data was stored in PermGen and had a fixed memory allocation.
-XX:MetaspaceSize
(formerly-XX:PermSize
) sets the initial high watermark of the metaspace at which a GC will be triggered. Defaults tounlimited
.-XX:MaxMetaspaceSize
(formerly-XX:MaxPermSize
) constrains the size of the class metadata area, which isn't constrained by default.-XX:MaxMetaspaceFreeRatio
sets the maximum permitted percentage of free metaspace space after a GC event, after which the metaspace should be shrunk. Defaults to 70%.-XX:MinMetaspaceFreeRatio
sets the minimum permitted percentage of free metaspace space after a GC event. Defaults to 40%.
Compressed class space
-XX:+UseCompressedClassPointers
is enabled for heaps below 32GB, using 32-bit offsets object->class references. When enabled, class metadata moves to a "Compressed class space" region within metaspace whose size is limited by-XX:CompressedClassSpaceSize
(which defaults to 1GB and can be set to a value to up to 3GB).-XX:+UseCompressedOops
enables use of compressed pointers for object references.
Run-time Constant Pool
Per-class or per-interface run-time representation of the class
file's constant_pool
table. Serves as a symbol table. Constructed when the class or interface is created by the JVM.
JVM throws OutOfMemoryError
if construction of the Run-time Constant Pool requires more memory than can be made available.
Entries in the constant pool can either be symbolic (may later be resolved) or static constants.
Code cache
The code cache stores native code compiled from bytecode.
-XX:InitialCodeCacheSize
and-XX:ReservedCodeCacheSize
set the initial and reserved code cache sizes.-XX:CodeCacheExpansionSize
-XX:-UseCodeCacheFlushing
enables flushing the code cache when free space falls below-XX:CodeCacheMinimumFreeSpace
(at most every-XX:MinCodeCacheFlushingInterval
).-XX:+ExitOnFullCodeCache
exits the JVM if the code cache fills.
Since SE 9 it can be broken into three segments if enabled with -XX:SegmentedCodeCache
(enabled by default if -XX:+TieredCompilation
is enabled and -XX:ReservedCodeCacheSize
is >= 240MB). These segments are not resizable at run-time:
- Non-method, which stores internal JVM code and data (such as the bytecode interpreter and compiler buffers). Its size is configurable via
-XX:NonNMethodCodeHeapSize
. - Profiled (less optimised) native code in
-XX:ProfiledCodeHeapSize
. - Non-profiled (optimised) native code
-XX:NonProfiledCodeHeapSize
When tuning the code cache size, use:
-XX:+PrintFlagsFinal
to see the final set of JVM flags after applying ergonomics heuristics.-XX:+PrintCompilation
logs compilatiom events, and might be useful in tuning code cache size.-XX:+PrintCodeCacheOnCompilation
to print usage each time a method is compiled.-XX:+PrintCodeCache
to print usage when the JVM exits.
Code cache usage looks like:
CodeCache: size=<reserved code cache size> used=<current usage> max_used=<peak usage> free=<free space within reservation>
bounds [0xb414a000, 0xb41d2000, 0xb614a000]
total_blobs=131 nmethods=5 adapters=63
compilation: enabled
With -XX:-SegmentedCodeCache
:
CodeHeap 'non-profiled nmethods': size=<non-profiled segment size> used=<current usage> max_used=<peak usage> free=free space within reservation>
bounds [0x00000001178ea000, 0x0000000117b5a000, 0x000000011ee22000]
CodeHeap 'profiled nmethods': size=<profiled segment size> used=<current usage> max_used=<peak usage> free=free space within reservation>
bounds [0x00000001103b3000, 0x0000000110e73000, 0x00000001178ea000]
CodeHeap 'non-nmethods': size=<non-profiled segment size> used=<current usage> max_used=<peak usage> free=free space within reservation>
total_blobs=5638 nmethods=4183 adapters=435
compilation: enabled
stopped_count=0, restarted_count=0
full_count=0
References
- The Structure of the Java Virtual Machine
- Loading, Linking, and Initializing
- Metaspace
- Class Metadata: A User Guide
- Introduction to JVM Code Cache
Children
Backlinks