CODEWITHSUNDEEP
javajvmstackqueue
Jaimin Patel
Jaimin Patel

Reputation: 4637

JVM : What is the great thing about "stack" that it used for JVM as a preferred choice to store locals?

Instead of Stack, Queue can also be used for it. Why JVM uses "Stack" for local variables and calls to methods for memory management? I already google my question but don't get exactly answer about it.

Upvotes: 2

Views: 520

Answers (4)

Holger
Holger

Reputation: 298123

It’s a fundamental, inevitable property of a thread’s code flow, that the last entered method will be the first to return from. Even in the exceptional case, where more than one method may be left, it will be the last n methods. Therefore, a LIFO data structure is the only choice, not just the “better” one.

That said, this kind of Stack is a logical concept, not an implementation requirement. The specification states:

Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6). A Java Virtual Machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java Virtual Machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java Virtual Machine stack does not need to be contiguous.

The last two sentences hint at the JVM’s freedom of how to implement that Stack. In fact, something like a linked list of heap allocated stack frames would be possible. However, providing efficient “push” and “pop” operations, to add and remove frames at the same end, is crucial.

In case the term Stack Frame needs clarifications:

A frame is used to store data and partial results, as well as to perform dynamic linking, return values for methods, and dispatch exceptions.

A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes, whether that completion is normal or abrupt (it throws an uncaught exception). Frames are allocated from the Java Virtual Machine stack (§2.5.2) of the thread creating the frame.

This relationship, i.e. the requirement to create and push a new frame on every method invocation and to pop and destroy it upon method completion, dictates how the Java Virtual Machine stack has to work.

Upvotes: 2

Andreas
Andreas

Reputation: 159086

This question has nothing to do with Java or JVM. Or rather, it is not specific to JVM, but is questioning the concept of a Call Stack, as implemented by pretty much all programming languages.

If you study how method calls work, in particular how the return from a method call is handled, and how local variables are stored with the call return information, you'd quickly realize that a call-queue would make no sense whatsoever.

Upvotes: 1

Dawood ibn Kareem
Dawood ibn Kareem

Reputation: 79808

In Java, when execution reaches a } character, any local variables that were declared since the matching { character go out of scope, and the memory that was used for them (references or primitive variables, not objects) can be reused. But the matching { character is the { that was encountered most recently, that has not yet been matched by a } character.

Therefore, variables go out of scope on a "most recently created" basis. Those most recently declared will be the ones that disappear first. Those that were declared earliest will be the last ones that disappear.

You couldn't do this with a queue. Local variables need to be in a "last in first out" structure such as a stack.

Upvotes: 4

gandalf
gandalf

Reputation: 118

As @Vince mentioned in the comment, Stack is Last-In-First-Out (LIFO) and a Queue is First-In-First-Out (FIFO) list.

When methods are called, they usually have a sequence like so,

  • method m1 calls method m2
  • method m2 calls method m3
  • method m3 calls method m4
  • ...

When method m4 returns, the execution returns to method m3.

When method m3 returns, the execution returns to method m2, and so on.

Finally method m1 finishes its execution.

Notice that method m1 was the first to get called, but the last to finish its execution. Thus storing method calls on a stack facilitates memory management (as stack is LIFO).

Local variables are declared and defined in methods, and are hence also stored on stack.

Upvotes: 7

Related Questions