Peter Quiring
Peter Quiring

Reputation: 1706

Java VM is the operand stack always empty at end of method

In a Java VM, at the end of a method when it returns does the operand stack contain just the return value (or empty for void methods). Or could there be other values under the return value that need to be discarded in the stack?

I'm creating each methods frame on the standard C stack. As shown in this image:

enter image description here

As you can see, the operand stack in the caller becomes the args in the callee frame. In the callee frame, would there be "junk" (other than the return value) on the operand stack that needs to be cleaned up before I restore my saved registers?

Upvotes: 4

Views: 680

Answers (3)

Holger
Holger

Reputation: 298213

See the documentation of return:

operand stack

... → [empty]

Description

… If no exception is thrown, any values on the operand stack of the current frame (§2.6) are discarded.

or ireturn, respectively:

operand stack

..., value → [empty]

Description

… If no exception is thrown, value is popped from the operand stack of the current frame (§2.6) and pushed onto the operand stack of the frame of the invoker. Any other values on the operand stack of the current method are discarded.

I think, this is giving enough hints that there might be values on the operand stack that have to be “discarded”, though, in typical implementations, no action is necessary as discarding the stack frame as a whole implies discarding the operand stack.

I’m not sure why this is an obstacle to you. If you really want to get the to the beginning of the stack frame by using the current operand stack position, you’ll need meta information about the stack frame anyway, i.e. you have to know the number of local variables in that frame. Retrieving this information and calculating the stack frame start, can’t be cheaper than retrieving the start of the frame in the first place.

Upvotes: 5

wero
wero

Reputation: 32980

A partial answer: The operand stack is part of a frame:

Each frame (§2.6) contains a last-in-first-out (LIFO) stack known as its operand stack.

and frame creation/destruction corresponds to method invocation/completion

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).

This does not give much insight about the operand stack when a method returns but at least it answers your question about the need to clean-up the operand stack: Since it is frame-local, there is no need for a clean-up since the operand stack is discarded along with its frame.

Upvotes: 1

Durandal
Durandal

Reputation: 20059

The question is hard to answer conclusively, because you do not specify precisely what you're asking about.

The specification is publically available https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf (See chapter 2.6.2)

This indicates that the stack may be in arbitrary state, at least when an uncaught exception occurs. I did not see an explicit mention of the return value, but since the return bytecode is specified to return a value from the stack value it must be on the stack (chapter 3.5).

The specification is just a description what happens logically. A real VM does not need to translate the specification 1:1 into a memory layout - it only needs to ensure the resulting logic is identical (think of JIT'd code).

Upvotes: 0

Related Questions