There are two reasons for writing this post. The first is my curiosity to understand how the memory part of JVM is operating. The second is that I believe, nowadays, some Java developers are becoming a simple JDK & JRE consumer.
I do not want to taint all my dear colleagues that way, but that’s what I’ve observed when I worked within some development teams.
The Java Virtual Machine is often seen, by a Java developer, as a black box doing code interpretations, optimisation…
All the focus is on code developement (true & false) while this layer is the main and unique link between the developed programme (standalone, web…) and the system (software: OS, and hardware as well) deploying it. I believe that understanding how this layer is operating mainly in memory management will have good effect on the manner we code with. Hmmm, How the JVM memory is organized and managed (allocation/deallocation)? According to wich rules the Garbage collector is executed?
Java is open source, it’s free and you could also develop your own customized JVM implementation, which will in turn intepret the code you write. This is a part of its richness..Well this is not easy and the question is whether you really need that or not. Generally, some enterprises need to choose a particular implementation, like IBM J9, OpenJDK… which can be open source or paid versions, or implement their own one. . Here you have a list of JVM implementations.
Differences between Java VM implementations
A JVM implementation could differs from another in:
- Java version used
- JIT implementation (optimization features)
- plateform support
- Other technologies integration like JEE servers
- Garbage collector …
- Other non-technical differences could be found , like license, opening the source code or not (JRocket is an implementation that as owned by BEA Systems. Nowadays, people talk about preparing a premium version developed by Oracle). However, all implementations must expose the same features in order to guarantee the same bytecode execution.
JVM memory organization: The HotSpot 7 stack
It’s the most used implementation in my opinion. The memory of the HotSpot 7 implementation is divided into zones respecting the manner in which objects are generated. In fact, each memory zone represents a particular objects generation and an appropriate Garbage Collector algorihtm is acting according to that generation.
As you can see below, the JVM has 3 generations or 3 zones:
- Young Space:
Young objects live in this part. This zone uses an algorithm derived from Stop&Copy which aim to manage short life-time objects and memory allocation. It is diveded into 3 segments:
- EDEN: All new objects (newly instanciated) are created in this part. It can be assimileted to a stack.
- Two survivor spaces SRV1 and SRV2: When the EDEN is saturated, the GC algorithm copy “survivor objects” (object still used and referenced in the application) to this SRV1 and then SRV2. After repeating this copying process many times, the GC could decide to tag the object as “old” and to move it to the Old Space . Besides, if an instance’s allowed memory exceeds a specific size, it will be placed directly in the Old Space: Integer vs YourClassXXXX, logic isn’t ?..When you instanciate a large class, the JVM will understand that it is an important object and will create it directly in Old Space which will save greatlty its collections by the GC alogorithm 😉
- Old Space or Tenured Space:
This space is managed by Mark and Sweep alogorithm which promotes moving objects and compacts memory: it divides the segment into two parts: one with objects and one without objects.
- PermGen Space:
All objects needing to survivor until the JVM has not been stopped, are in this zone. Class attributes (static final attibute) for example are placed directly in this zone. This space has been removed in Java 8. It’s one of this new version features