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. > What I was expecting that the Java model was trying to do (though I > didn't find this) was something along these lines: "Accessing the main > store involves locking, so by copying things to a thread-local store we > can perform several operations on an item before we have to move it > back to the main store (again, with locking). If we worked directly > from the main store, we'd have to lock for each and every use of the > variable." I don't believe accesses to main store require locking in the JVM. 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. - Damien