If you have been a java developer and you should came across java garbage collection that free the object created by your application from occupied all the java heap. In today article, we will look into java heap and particular into
java eden space. First, let's look at the general java heap.
From
this StackOverflow
Heap memory
The heap memory is the runtime data area from which the Java VM allocates memory for all class instances and arrays. The heap may be of a fixed or variable size. The garbage collector is an automatic memory management system that reclaims heap memory for objects.
Eden Space: The pool from which memory is initially allocated for most objects.
Survivor Space: The pool containing objects that have survived the garbage collection of the Eden space.
Tenured Generation: The pool containing objects that have existed for some time in the survivor space.
When you created a new object, jvm allocate a part of the heap for your object. Visually, it is something as of following.
+-----+
| |
<-minor gc-> v v <------------- major gc---------------------->
+------------+-----+-----+----------------------------------------------+-------------+
| | | | | |
| Eden | S0 | S1 | Tenure Generation | Perm gen |
| | | | | |
+------------+-----+-----+----------------------------------------------+-------------+
<---------------------jvm heap (-Xms -Xmx)----------------------------> -XX:PermSize
<-- young gen(-Xmn)----> -XX:MaxPermSize
When eden space is fill with object and
minor gc is performed, survive objects will copy to either survivor spaces;
s0 or
s1. At a time, one of the survivor space is empty. Because the eden space are relatively small in comparison to the tenure generation, hence, the gc that happened in eden space is quick. Eden and both survivors spaces are also known as
young or new generation.
To understand into how young generation heap get free,
this article provided detail explanation.
The Sun/Oracle HotSpot JVM further divides the young generation into three sub-areas: one large area named "Eden" and two smaller "survivor spaces" named "From" and "To". As a rule, new objects are allocated in "Eden" (with the exception that if a new object is too large to fit into "Eden" space, it will be directly allocated in the old generation). During a GC, the live objects in "Eden" first move into the survivor spaces and stay there until they have reached a certain age (in terms of numbers of GCs passed since their creation), and only then they are transferred to the old generation. Thus, the role of the survivor spaces is to keep young objects in the young generation for a little longer than just their first GC, in order to be able to still collect them quickly should they die soon afterwards.
Based on the assumption that most of the young objects may be deleted during a GC, a copying strategy ("copy collection") is being used for young generation GC. At the beginning of a GC, the survivor space "To" is empty and objects can only exist in "Eden" or "From". Then, during the GC, all objects in "Eden" that are still being referenced are moved into "To". Regarding "From", the still referenced objects in this space are handled depending on their age. If they have not reached a certain age ("tenuring threshold"), they are also moved into "To". Otherwise they are moved into the old generation. At the end of this copying procedure, "Eden" and "From" can be considered empty (because they only contain dead objects), and all live objects in the young generation are located in "To". Should "to" fill up at some point during the GC, all remaining objects are moved into the old generation instead (and will never return). As a final step, "From" and "To" swap their roles (or, more precisely, their names) so that "To" is empty again for the next GC and "From" contains all remaining young objects.
As you can observed based on the visual diagram above, you can set the amount of heap for the eden and survivor space using -
Xmn in the java parameter. There is also
-XX:SurvivorRatio=ratio and you can find further information here for
java8. Note that in the diagram above, Perm gen has been removed in java8, hence always refer find out what java run your application and refer to the right version of java documentation.
If you want to monitor the statistics of eden , you can use
jstats. Previously I have written an article about jstat and you can read
here what is jstat and how to use it. You can also enable
gc log statistics and so jvm will write the gc statistics into a file, you can further
read more here.
Till then we meet again in the next article. Please consider donate, thank you!
