57

The compiler book(The dragon book) explains that value types are created on the stack, and reference types are created on the heap.

For Java, JVM also contains heap and stack in runtime data area. Objects and arrays are created on heap, method frames are pushed to stack. One heap is shared by all threads, while each thread has its own stack. The following diagram shows this:

enter image description here

More about Java run-time data areas.

What I don't understand is that since JVM is essentially a software, how are those JVM heap, stack and threads mapped to physical machine?

I would appreciate it if someone can compare those concept between Java and C++. Because Java runs on JVM, but C++ does not.

To make this question more precise, I want to know the following:

  1. Comparing with Java, What does C++ run-time data area look like? A picture would be helpful, I can't find a good picture like the JVM one above.
  2. How the JVM heap, stack, registers and threads are mapped to operating system? or I should ask how they are mapped to physical machine?
  3. Is it true that each JVM threads is simply a user thread and gets mapped to kernal in some way? (user thread vs kernel thread)

Update: I draw a picture for runtime physical memory of a process.
enter image description here

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
Ryan
  • 2,825
  • 9
  • 36
  • 58
  • 3
    mostly threads just map to OS threads, at which point they get their own stack, same as any thread on the OS. – radai Apr 28 '13 at 14:57
  • @radai Great, Thanks for comment! Can you say more by comparing Java with C++? – Ryan Apr 28 '13 at 15:21
  • i'm not knowledgable in c++ to really make the comparison, i just know the java end. – radai Apr 28 '13 at 16:06

1 Answers1

39

What I don't understand is that since JVM is essentially a software, how are those JVM heap, stack and threads mapped to physical machine?

The heap is a pre-allocated continuous region of virtual memory. e.g.

 void* heap = malloc(Xmx); // get the maximum size.

The stacks are allocated by the threading library when the thread is started. Again it is a continuous region of virtual memory which is the maximum stack size. Again you could think of it as

 void* stack = malloc(Xss); // get the maximum stack size.

Native threads are OS features which are not part of the JVM space as such.

Because Java runs on JVM, but C++ does not.

C++ still needs a runtime environment and libraries to start up. Try deleting your C++ Runtime or libc and these won't start.

Comparing with Java, What does C++ run-time data area look like?

There is one large region of virtual memory you can use. There isn't a picture because it wouldn't tell you much. Imagine one long rectangle labelled user space.

How the JVM heap, stack, registers and threads are mapped to operating system? or I should ask how they are mapped to physical machine?

Again there is no magic. The JVM heap is a region of memory, a JVM stack is the same a native stack which is what C+ uses, the JVM's registers is the same as native registers which is what C+ uses and JVMs thread are actually native threads which is what C+ uses.

I think you are assuming there is more magic or obscurity going on than there is. Instead you should assume that the simplest, efficient and lightweight design has been used and you won't be far off.

I should ask how they are mapped to physical machine?

one to one basically.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks a lot. In your answer, by saying "labelled user space", do you mean labelled with each process? JVM thread is mapped to kernel "one to one"? – Ryan Apr 28 '13 at 21:22
  • Native thread stacks are in the user-space memory of the process. I don't know what you mean by 'JVM space as such' if it excludes these. – user207421 Apr 28 '13 at 22:33
  • Am I right that memory for jvm heap is allocated from data segment of the OS process that represents jvm? My assumption is based on that jvm is essentially just a process, and each process has text, data, and stack segments, and malloc() essentially grabs a slab of memory from the data segment. Am I right? – Rustam Issabekov May 09 '13 at 05:11
  • The HotSpot JVM grabs a large continuous region of virtual memory for the heap, it could use `malloc` to do this. By "data" segment, I assume you are talking about the different segments the x86 used from the 8086 to address more memory. AFAIK, these don't really come into play and the JVM runs on architectures which don't have these. – Peter Lawrey May 09 '13 at 05:41
  • "The stacks are allocated by the threading library when the thread is started. Again it is a continuous region of virtual memory" - not according to the [*docs*](http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.5.2): `The memory for a Java Virtual Machine stack does not need to be contiguous.` – Nir Alfasi Oct 30 '13 at 18:09
  • @alfasin The stack space used by a JVM might not be continuous, the stack space for an individual thread is usually continuous as doing anything else would be needlessly complicated/expensive. – Peter Lawrey Oct 30 '13 at 21:04
  • @PeterLawrey you're right - it makes sense as long as the implementation uses fixed-size stacks. – Nir Alfasi Oct 30 '13 at 21:17
  • @alfasin The size is fixed in terms of virtual memory. This means you can have a 10 MB stack but only the pages accessed use main memory. – Peter Lawrey Oct 30 '13 at 21:30
  • @PeterLawrey exactly, and when VM is used it's probably not going to be continuous. – Nir Alfasi Oct 30 '13 at 21:34
  • @alfasin but given memory is random access, the pages could be anywhere but it doesn't matter. All the program see is a continuous address space. – Peter Lawrey Oct 30 '13 at 21:43
  • @PeterLawrey that's correct for data that was fetched from the VM (disc) to RAM. If we need to read data from two separate locations on the HD there will be penalty. Luckily, today, the RAM is big enough to hold the whole stack - so in practice your point is totally valid. – Nir Alfasi Oct 30 '13 at 22:10