JVM PermGen – where art thou?
This post covers some basics of JVM memory structure and quickly peeks into PermGen to find out where it has disappeared since advent of Java SE 8
The JVM is just another process running on your system and the magic begins with the java command. Like any OS process, it needs memory for its run time operations. Remember – the JVM itself is a software abstraction of a hardware on top of which Java programs run and boast of OS independence and WORA (write once run anywhere)
Quick coverage of the JVM memory structure
As per the spec, JVM is divided into 5 virtual memory segments.
- Method (non heap)
- JVM Stack
- Native Stack
- PC Registers
- Shared by all threads
- The JVM throws when it’s exhausted
- Use the -Xms and -Xmx JVM options to tune the Heap size
- Also called the non heap area (in HotSpot JVM implementation)
- It is divided into 2 major sub spaces
Permanent Generation – This area stores class related data from class definitions, structures, methods, field, method (data and code) and constants. Can be regulated using -XX:PermSize and -XX:MaxPermSize. IT can cause: PermGen space if it runs out if space
Code Cache – The cache area is used to store compiled code. The compiled code is nothing but native code (hardware specific) and is taken care of by the JIT (Just In Time) compiler which is specific to the Oracle HotSpot JVM
- Has a lot to do with methods in the Java classes
- Stores local variables and regulates method invocation, partial result and return values
- Each thread in Java has its own (private) copy of the stack and is not accessible to other threads.
- Tuned using -Xss JVM option
- Used for native methods (non Java code)
- Per thread allocation
- Program counter specific to a particular thread
- Contains addresses for JVM instructions which are being exceuted (undefined in case of native methods)
So, that’s about it for the JVM memory segment basics. Coming to back to the Permanent Generation.
So where is PermGen ???
Essentially, the PermGen has been completely removed and replaced by another memory area known as the Metaspace
Metaspace – quick facts
- It’s part of the native heap memory
- Can be tuned using -XX:MetaspaceSize and -XX:MaxMetaspaceSize
- Clean up initiation driven by XX:MetaspaceSize option i.e. when the MetaspaceSize is reached.
This was obviously just the tip of the iceberg. For comprehensive coverage of the JVM, there is no reference better than the specification itself 🙂
(Additional note – thanks to inputs by Jon Diamond)
Note: The JVM specification itself is a standard for vendors (who implement the spec to build their own JVM) to follow. It should not be used to figure out vendor specific features (e.g. SAP JVM might implement a spec feature differently than that of the Oracle HotSpot VM). The JVM specification provides scope for innovation by not enforcing each and every minor details w.r.t implementation. In fact, we are living in the age of Polyglot Languages – which compile to byte code supported by the JVM (Scala, Groovy, JPython, JRuby, Kotlin etc). But for most of us out there – it can be leveraged to gain a solid understanding of the Java fundamentals ranging from bytecode to class loading process