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
