VM experts, please resolve dispute re

Question

Over in "Advanced Topics",
http://forum.java.sun.com/thread.jsp?forum=4&thread=167222
dnoyeB and I are having a spirited discussion about the mechanics of thread working copies vs. main mem's master copy. It's a very long discussion that spawned off from somebody else's simple question "When do you use volatile vs. synchronized." Our disagreement doesn't start until about message 30 or 40, but here are the main points of contention:
* dnoyeB says that a thread's working copy of a variable is by necessity on the stack, and that therefore, every time a method exits, that thread's working copies (or at least those used by the method) are flushed back to the master copy.
* I claim that this is not the case, and that one legal model is for a thread's working copy to be in a CPU's cache. I think that dnoyeB's model is unwieldy at best, and not doable at worst.
* I claim that a thread can directly access variables on the heap.
* dnoyeB claims that a thread cannot access the heap directly and must alway access variables via the stack.
Chapter 3 of the VM spec and Chapter 17 of the JLS are involved heavily in this discussion.
Please set us straight. :-)
Thanks,
Jeff

Answer 1

I am beginning to think we were both right and wrong.I disagree. See below for why.
1. the only thread local copies of variables are in
the operand stack, not in a frame. This is still the
stack so method ending does flush the stack var.I am using the terminology from the JVM spec and Venners' book. When I said operand stack and thread stack I meant essentially the same thing.
void func()
obj.x +=2;
obj.x +=2;
}according to the spec
if x is not volatile, after the first add, x is still
on the operand stack, and can be used directly from
the operand stack. If x were volatile, it would have
to be written back to main mem after the first write,
and reloaded for the second.You are completely wrong. You are equating memory used for holding the stack frames (which holds: local vars, operand stack, and frame data) with thread-local memory view. obj.x can live in this thread's local memory (which holds: class and instance fields, array elements that are used by methods in this thread; they live there in-between method calls, if you want).
What you seem to be saying is that if you have a method implemented as
int getX ()
    return obj.x;
}then [in your opinion] this method will automatically return the most-up-to-date, out-of-main memory value of obj.x even if x is not volatile?
If x were volatile, it would have
to be written back to main mem after the first write,
and reloaded for the second.In other words, you are saying that in the scenario
thread 1                                     thread 2
getX();                                      ...
...                                             obj.x = new_value
getX();                                      ...         the second getX() by thread 1 is guaranteed to see the new_value for obj.x even if it is not volatile, just because the operand value had to be popped off the operand stack in between the calls to getX()?
This is clearly incorrect. As has been stated several times already, you are incorrectly assuming that method boundaries act as memory barriers in the JMM sense. They do not.
You trying to imply that the acts of pushing and popping values to/from the operand stack are the actual events of reconciling thread-local memory with main memory. This is incorrect. If Java bytecode was designed around the usual register-only abstract architecture then where would you be? There would be no stack frames but there would still be a need for a memory reconciliation model across threads/CPUs.
Why can't you acknowledge than a thread-local memory can actually map onto the CPU's local memory and Java is the first common programming language that attempted to define a memory coherency model for a concurrent runtime? All other langugages silently assume that you inherit the memory model from the underlying hardware.
Vlad.