0

Say, we have a VM, which has a stack. The stack's length must be variable. Then the stack itself must be allocated on heap, because the VM needs to request memory for the stack at runtime. So all the objects in that stack are actually allocated on heap, too. I wonder if this guess holds true for all stack-based languages.

This not a questing specifically for JVM. I just learned that JVM is both stack and register based. My question is that, for languages of only stack-based VMs, is it possible to allocate objects on the OS stack? And if possible, how can that be implemented?

taotsi
  • 354
  • 2
  • 11
  • Does this answer your question? [What and where are the stack and heap?](https://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) – akuzminykh Aug 11 '20 at 15:50
  • @akuzminykh I'm afraid it doesn't. – taotsi Aug 11 '20 at 15:57
  • That is not the reason, the reason has to do with simplicity, deciding that objects cannot escape the method call (and thus can be stack allocated) is not easy. Thus it is easier to do the same as with all other objects: allocate them on the heap. That said, there are some efforts underway to improve escape analysis and allow stack allocation. – Mark Rotteveel Aug 11 '20 at 15:58
  • @MarkRotteveel So it's possible to allocate objects on stack, the real stack? – taotsi Aug 11 '20 at 16:02
  • 1
    You have to distinguish the conceptual high-level view from how JVMs are actually implemented. For example, modern JVMs often avoid object allocation entirely by doing something called [scalar replacement](https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/). The program still *behaves as if* an object was allocated (on the heap), but in reality no such allocation happens. But optimizations like this are possible largely *because* the high-level view is relatively simple (i.e. any optimization that looks as though we did exactly what the high-level view suggests is acceptable). – Joachim Sauer Aug 11 '20 at 16:04
  • 1
    @taotsi You cannot control it yourself. If the vm detects that the object will not leave (escape) the current context, then it might be allocated on the stack instead. – Erik Aug 11 '20 at 16:05
  • What is "the real stack" to you @taotsi? – Joni Aug 11 '20 at 16:08
  • @Joni stack from the OS, not the VM, like those of compiled languages. – taotsi Aug 11 '20 at 16:19
  • Ah ok. First: A native program may request to resize the space reserved for the stack at run time, that doesn't mean "the stack is allocated on the heap". Second: Interpreted languages may manage their own stack in the interpreter. This stack would be allocated on the heap. The interpreter also uses the OS stack for its own purposes, for its own internal function calls. – Joni Aug 11 '20 at 16:38
  • @Joni OK, let's see an example. In an interprete language, you create a local variable `x`, an intergen for example(which is definitely unnecessary to be allocated on heap in compiled languages because stack is faster). And when the instruction pointer goes into `x`s scope and sees it, the interpreter would probably hold a piece of memory for `x`(according to my knowledge) on the top of the VM stack. Is it possible that `x` is actually on the OS stack? If possible, how could that VM stack be implemented? – taotsi Aug 11 '20 at 16:59
  • The interpreter needs a data structure to store the local variables. This data structure could allocated on the stack, which is an option available in C and C++. In this case `x` would be on the OS stack. Also in this case, it wouldn't make too much sense to maintain a interpreted language VM stack data structure separate from the host interpreter OS stack. Interpreted function calls would have to be implemented as interpreter function calls. – Joni Aug 11 '20 at 18:03

0 Answers0