0

Java heap only stores objects, and stack only stores primitive data and object reference.

Consider A.a = B.b , where A.a and B.b are int.

In my understanding, a JVM will first GET the value of A.a from the heap to the stack, and then PUT the value to B.b which is on the heap. It seems that the only way to change data on heap is to PUT the value from the stack.

My question is: is there some way to operate data on Java heap without stack? E.g., copy the value of A.a direct to B.b without stack operation.

If you say "it depends on the implementation of JVM", then my question is about Dalvik.

trincot
  • 317,000
  • 35
  • 244
  • 286
Yubin Xia
  • 65
  • 5

3 Answers3

2

As far as the abstract machine called JVM (not to be confused with the various pieces of software which go by the same name and implement that abstract machine by mapping it onto real hardware) is concerned, A.a = B.b does indeed load the value of B.b on the stack, then stores it to A.a.1

However, as the name abstract machine may tell you, this is only a way of thinking about semantics. An implementation may do whatever it pleases, as long as it preserves the effect of the program. As you should know, most implementations don't actually interpret JVM instructions most of the time, but instead compile it to machine code for the CPU they run on. If you're concerned about performance or memory traffic, you need to go deeper.

When compiling, the JVM's stack is mostly discarded in favor of the registers most physical CPUs use. If there aren't enough registers available, the hardware stack (which is distinct from the JVM stack!) may also be used. But I digress. On most architectures, there's no instruction for moving from one memory location to the other (see Assembly: MOVing between two memory addresses). However, the hardware stack is also memory, so it's actually impossible to go heap -> stack -> heap. Instead, you'll find that the code loads the value from memory into a register, then stores it to memory from a register.

Finally, if the objects A and B are short-lived and aren't aliased, they may even be elided with their fields ending up on the stack or in registers. Then, this operation becomes even simpler (or may even be removed entirely if it has no effect).

1 These two steps actually take several JVM instructions each, but that's not important here.

Community
  • 1
  • 1
  • Thanks for the answer. When considering JIT, things get complicated. I think my question is actually about Java compiler, not JVM... Thanks again. – Yubin Xia May 04 '13 at 10:55
1

When considering JIT, things get complicated. I think my question is actually about Java compiler, not JVM

If you are thinking of the javac you should assume that it does almost no optimisation and gives in byte code almost a literal translation of the code, which is very stack based.

In fact the byte code will be using the stack more than your example suggests. It does operations like

push B
getAndPushField b
push A
popAndSetField a

i.e. instead of one stack operation, there is notionally 3.

The JIT on the other hand might optimise this away so it is not even using a register for the value. Depending on the processor

// R3 contains A, R7 contains B, 
// a starts at the 14th byte
// b start at the 16th byte
MOVI [R3+14], [R7+16]
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

It doesn't depend on the implementation of the JVM. It depends on the Java Virtual Machine Specification, which doesn't provide any other way than via the stack.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Assuming you're only thinking about the abstract machine and ignore what happens on the physical machine. –  May 04 '13 at 09:59
  • 1
    Thanks for the answer. I have an counter-example but I'm not sure: consider `clone()` of an object, which will finally invoke a native method that uses malloc() and memcpy() to create a new object on the Java heap and then return the reference. In this way, I actually copy the value of `old_obj.field` to `new_obj.field` without put the value on to the stack, right? Is it a kind of bypassing? – Yubin Xia May 04 '13 at 10:48