JVM from the inside - memory organization inside the Java process
Probably everyone working with Java is aware of memory management at the level that the garbage collector is used to allocate it. Unfortunately, not everyone knows exactly how this collector (s) works, and how exactly the memory is organized within the Java process.
Because of this, sometimes the wrong conclusion is made that there is no memory leaks in Java, and you don’t need to think too much about memory. Holivars also often go about excessive memory consumption.
Everything described below refers to the Sun-JVM (HotSpot) implementation of versions 5.0+, specific details and algorithms may vary for different versions.
So, the process memory differs in heap (heap) and non-heap (stack) memory, and consists of 5 areas (memory pools, memory spaces):
• Eden Space (heap) - in this area will be allocated memory for all objects created from the program. Most of the objects live for a short time (iterators, temporary objects used inside methods, etc.), and when performing garbage collections, these are areas of memory that are not moved to other areas of memory. When a given area is filled (i.e., the amount of allocated memory in this area exceeds a certain percentage), the GC performs a quick (minor collection) garbage collection. Compared to full garbage collection, it takes little time, and only affects this area of memory — Eden Space clears obsolete objects and moves surviving objects to the next area.
• Survivor Space (heap) - objects from the previous one are moved here after they have survived at least one garbage collection. From time to time, long-lived objects from this area are moved to Tenured Space.
• Tenured (Old) Generation (heap) - Long-lived objects accumulate here (large high-level objects, singletones, resource managers, etc.). When this area is filled, a full garbage collection (full, major collection) is performed, which processes all the created JVM objects.
• Permanent Generation (non-heap) - The meta information used by the JVM (classes used, methods, etc.) is stored here. In particular
• Code Cache (non-heap) - this area is used by the JVM, when JIT compilation is enabled, it caches the compiled platform-dependent code.
')
This is where blogs.sun.com/vmrobot/entry/the basics of collection_ of garbage_v_hotspot have a good description of the work of garbage collectors. I see no point in reprinting, I advise anyone interested to read more about the link.
The article is not mine. but comrade Zorkus ' a, who would like to get an invite :).
Because of this, sometimes the wrong conclusion is made that there is no memory leaks in Java, and you don’t need to think too much about memory. Holivars also often go about excessive memory consumption.
Everything described below refers to the Sun-JVM (HotSpot) implementation of versions 5.0+, specific details and algorithms may vary for different versions.
So, the process memory differs in heap (heap) and non-heap (stack) memory, and consists of 5 areas (memory pools, memory spaces):
• Eden Space (heap) - in this area will be allocated memory for all objects created from the program. Most of the objects live for a short time (iterators, temporary objects used inside methods, etc.), and when performing garbage collections, these are areas of memory that are not moved to other areas of memory. When a given area is filled (i.e., the amount of allocated memory in this area exceeds a certain percentage), the GC performs a quick (minor collection) garbage collection. Compared to full garbage collection, it takes little time, and only affects this area of memory — Eden Space clears obsolete objects and moves surviving objects to the next area.
• Survivor Space (heap) - objects from the previous one are moved here after they have survived at least one garbage collection. From time to time, long-lived objects from this area are moved to Tenured Space.
• Tenured (Old) Generation (heap) - Long-lived objects accumulate here (large high-level objects, singletones, resource managers, etc.). When this area is filled, a full garbage collection (full, major collection) is performed, which processes all the created JVM objects.
• Permanent Generation (non-heap) - The meta information used by the JVM (classes used, methods, etc.) is stored here. In particular
• Code Cache (non-heap) - this area is used by the JVM, when JIT compilation is enabled, it caches the compiled platform-dependent code.
')
This is where blogs.sun.com/vmrobot/entry/the basics of collection_ of garbage_v_hotspot have a good description of the work of garbage collectors. I see no point in reprinting, I advise anyone interested to read more about the link.
The article is not mine. but comrade Zorkus ' a
Source: https://habr.com/ru/post/84165/
All Articles