Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JVM Memory segments allocation

Alright so I have a question regarding the Memory segments of a JVM, I know every JVM would choose to implement this a little bit different yet it is an overall concept that should remain the same within all JVM's

A standart C / C++ program that does not use a virtual machine to execute during runtime has four memory segments during runtime, The Code / Stack / Heap / Data all of these memory segments are automatically allocated by the Operating System during runtime.

However, When a JVM executes a Java compiled program, during runtime it has 5 Memory segments

The Method area / Heap / Java Stacks / PC Registers / Native Stacks

My question is this, who allocates and manages those memory segments? The operating system is NOT aware of a java program running and thinks it is a part of the JVM running as a regular program on the computer, JIT compilation, Java stacks usage, these operations require run-time memory allocation, And what I'm failing to understand Is how a JVM divides it's memory into those memory segments. It is definitely not done by the Operating System, and those memory segments (for example the java stacks) must be contiguous in order to work, so if the JVM program would simply use a command such as malloc in order to receive the maximum size of heap memory and divide that memory into segments, we have no promise for contiguous memory, I would love it if someone could help me get this straight in my head, it's all mixed up...

like image 593
DrPrItay Avatar asked Sep 26 '22 07:09

DrPrItay


1 Answers

When the JVM starts it has hundreds if not thousand of memory regions. For example, there is a stack for every thread as well as a thread state region. There is a memory mapping for every shared library and jar. Note: Java 64-bit doesn't use segments like a 16-bit application would.

who allocates and manages those memory segments?

All memory mappings/regions are allocated by the OS.

The operating system is NOT aware of a java program running and thinks it is a part of the JVM running as a regular program on the computer,

The JVM is running as a regular program however memory allocation uses the same mechanism as a normal program would. The only difference is that in Java object allocation is managed by the JVM, but this is the only regions which work this way.

JIT compilation, Java stacks usage,

JIT compilation occurs in a normal OS thread and each Java stack is a normal thread stack.

these operations require run-time memory allocation,

It does and for the most part it uses malloc and free and map and unmap

And what I'm failing to understand Is how a JVM divides it's memory into those memory segments

It doesn't. The heap is for Java Objects only. The maximum heap for example is NOT the maximum memory usage, only the maximum amount of objects you can have at once.

It is definitely not done by the Operating System, and those memory segments (for example the java stacks) must be contiguous in order to work

You are right that they need to be continuous in virtual memory but the OS does this. On Linux at least there is no segments used, only one 32-bit or 64-bit memory region.

so if the JVM program would simply use a command such as malloc in order to receive the maximum size of heap memory and divide that memory into segments,

The heap is divided either into generations or in G1 multiple memory chunks, but this is for object only.

we have no promise for contiguous memory

The garbage collectors either defragment memory by copying it around or take steps to try to reduce it to ensure there is enough continuous memory for any object you allocate.

would love it if someone could help me get this straight in my head, it's all mixed up...

In short, the JVM runs like any other program except when Java code runs it's object are allocated in a managed region of memory. All other memory regions act just as they would in a C program, because the JVM is a C/C++ program.

like image 78
Peter Lawrey Avatar answered Sep 30 '22 12:09

Peter Lawrey