On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:...On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:Yes, that's what I'm saying. I don't see an advantage of JVMs multi-step variable access, because it even doesn't provide such atomic access.
You're missing the point of the multi-step access. It has nothing to do with threading or atomic access to variables.
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to operate
on a variable, therefore, it must first copy it from main store to thread-
local store (the stack).
Parrot, so far as I know, operates in exactly the same way, except that the thread-local store is a set of registers rather than a stack.
Both VMs separate working-set data (the stack and/or registers) from main store to reduce symbol table lookups.
This will all make a lot more sense if you keep in mind that Parrot-- unthreaded as it is right now--*also* copies variables to working store before operating on them. This isn't some odd JVM strangeness. The JVM threading document is simply describing how the stack interacts with main memory.
I think the JVM spec actually implying something beyond this. For instance section 8.3 states, "A store operation by T on V must intervene between an assign by T of V and a subsequent load by T of V." Translating this to parrot terms, this would mean that the following is illegal, which it clearly isn't:
find_global P0, "V"
set P0, P1 # "assign by T of V"
find_global P0, "V" # "a subsequent load by T of V" w/o an intervening "store operation by T on V"
I think it is talking about something below the Java-bytecode level--remember, this is the JVM spec, and constrains how an implementation of the JVM must behave when executing a sequence of opcodes, not the rules a Java compiler must follow when generating a sequence of opcodes from Java source code.
What I think it's really saying, again translated into Parrot terms, is this:
store_global "foo", P0 # internally, may cache value and not push to main memory
find_global P0, "foo" # internally, can't pull value from main memory if above value was not yet pushed there
and I think the point is this:
find_global P0, "foo" # internally, also caches value in thread-local storage
find_global P0, "foo" # internally, can use cached thread-local value
And, as mentioned in section 8.6, any time a lock is taken, cached values need to be pushed back into main memory, and the local cache emptied. This doesn't make any sense if the "thread's working memory" is interpreted as the stack.
JEff
