0

This is with reference to the answer in this post: How JVM stack, heap and threads are mapped to physical memory or operation system

it says "JVM stack is the same a native stack" if that is the case then how jvm allocates stack frames on this stack memory whenever there is a function call in Bytecode and not the JVM code function call. If there is a function call in JVM code then the method local variables and other method related stuff will be stored in this native stack by OS. But if there is a function call in bytecode instruction how does JVM manually stores locals in that native stacks.

Community
  • 1
  • 1
Ankush G
  • 989
  • 9
  • 14
  • The Java Virtual Machine specification and the Java Language Specification only speak about stack frames as an abstraction. The details are left up to whoever actually implements a JVM. If you really want to understand it at such a low level, you might as well dive into the OpenJDK source code: http://openjdk.java.net/ – Solomon Slow Jul 27 '16 at 16:41
  • Why are you asking this question? Is it just curiosity or is there a goal here? – Gray Jul 27 '16 at 22:18

1 Answers1

2

how jvm allocates stack frames on this stack memory whenever there is a function call in Bytecode and not the JVM code function call.

Exactly what the JVM isn't specified in the JLS. The JVM might

  • allocate a stack frame.
  • reuse an existing stack frame for a leaf method.
  • inline a method so it doesn't require it's own frame.

In terms of byte code, different portions of a method can have their own frames, and the JVM might allocate multiple frames in a method, though I doubt it actually does this.

If there is a function call in JVM code then the method local variables and other method related stuff will be stored in this native stack by OS.

Always, unless the variable is optimise away in which case it doesn't get stored anywhere.

But if there is a function call in bytecode instruction how does JVM manually stores locals in that native stacks.

The byte code has to run on a real machine and it has to use the stack to store it's information, this doesn't change dramatically based on whether it running in interpreted byte code or compiled native code. The only difference is how much optimisation has occurred in reducing the number of local variables.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks for this explanation. This is what i think: JVM being the real code for underlying machine, whenever there is function call in JVM(in java.exe code), the stacks stuff is managed by that underlying machine because it knows there is a function call happened. But while interpreting bytecode, if there is function call in that ByteCode, how does and who does manage the stack stuff for that function call, because only interpreting JVM knows about the function call and not the underlying machine. Your help is highly appreciated. – Ankush G Jul 28 '16 at 03:38
  • @shyampatil the stack is just a region of memory which has a stack pointer. Memory is allocated by moving the pointer up and freed by moving the pointer down. In the byte code it has all the local variable allocation determined at compile time. i.e. it allocates the real stack when a method is entered and frees when it leaves even when running in interpreted mode. – Peter Lawrey Jul 28 '16 at 06:56
  • 1
    Ohh!! what a relief!! Thank you so much for such precise and valuable explanation. Appreciate your time and patience. :-) – Ankush G Jul 28 '16 at 07:47