Saturday, September 14, 2013

Inside Java - JVM Memory Structure 2

Hi folks,

In this post we will continue the  quick intro we talked in last post. Let's start with an overview of JVM memory:

The diagram above summarise the basic structure of the JVM that we can find in Oracle HotSpot and OpenJDK IceTea (funny name isn't it? =D). 

Java starts with many threads (all Threading in Java uses the native threads, where you can use the Operational System's tools to look these threads and extract information about them - the other way would be with Green Threads where there is only real thread). Each Thread has its responsibility and work to do, like C2 thread is for JIT compiling and GC thread to run the Garbage collector. Your simple "Hello World" is running in a specific Thread creating by default by the JVM. The Threads in Java have some basic structure in common, one of them is the Stack memory, where each thread contains the Frames, like the state of each call you are doing in with that specific thread (like which method, the local variables of that method and etc).

There are some shared memory in the JVM. The Method Area (known as PermGen) is the area where the definition of classes and its meta information (for example the JIT references, JIT is the native code generated by the JVM which is faster than interpreted code) are available. The PermGen can give OutOfMemory when you loaded too many classes. Like other features in the JVM, there are many options that you can use to optimize the throughput and for latency.

But one of the most famous part of the JVM is the Heap. It is stored there the live objects. It is very complex (specially to optimise it, there are people who just work monitoring and enhancing the performance of JVM), so I will try to put in a simple way (removing some difficult concepts that it have). Basically when you create any object, the JVM will save it in the Heap, inside the Young area, and due it is very new, it will be in Eden space (just to make clear, like in the picture, the Young memory space have sub-spaces like Eden). If your object is not in use, it will be removed by Garbage Collector (GC) (this happens in all the spaces, only in the Stack space it doesn't). As the time goes, the objects are migrating to another spaces in the Heap. It will move to the Survivor Space (SS#1)(SS#2) and then (finally) to Old/Tenured Space. The expected JVM behavior is that each of those moves between spaces, less objects are removed. There is two special events associate with the Heap, I just called "removed" but there is two types of it that Garbage Collector (GC) is resposible: Scavenge and Stop-the-world events. The Scavenge is when the JVM do a normal job (removing objects of the Heap), the threads keep running as usual, just the GC Thread that consume more CPU to remove some objects. But in some cases it need to guarantee that no thread will interfere in its job, so it need to run a Stop-the-world event so all thread stop working to the GC collect some objects in the Heap. The simplification of a fine tuned JVM is that each migration between the each memory area, the number of data is lower each time, so most of objects are created and die in Eden and fewer go to the next area and so on. That with few GC events pauses increases the throughput of the JVM/your application.

In the next post (tomorrow) I will talk more about GC. Hope to see you there! Thank you vey much for attention and everything else!!

No comments:

Post a Comment