On Wed, Jan 14, 2004 at 10:28:25PM -0800, Jeff Clites wrote: > You might be right, but that's not exactly how I read it, because later > it says, "A use action (by a thread) transfers the contents of the > thread's working copy of a variable to the thread's execution engine. > This action is performed whenever a thread executes a virtual machine > instruction that uses the value of a variable."
There are three locations where a variable's data may be present: - Main memory, which all threads may access. - Working memory, which is thread-private. (The thread's stack and/or registers, depending on VM design.) - The execution engine--the low-level code (probably C or C++), which implements the VM's opcodes. The "use" action refers to the execution of a JVM opcode which uses data from a thread's stack. > In any case, I thought this sounded like an interesting model, but > based on the rules in that section about how accesses to data in the > thread-local store have to correspond to accesses of the main store, it > wasn't apparent to me how there was an advantage over just accessing > things directly out of the main store. But I assume I'm overlooking > some subtlety, and that there may be an idea here that we could use to > our advantage. The JVM disallows accesses from main store for the same reason Parrot does--bytecode efficiency. JVM opcodes operate on the stack, as Parrot opcodes operate on registers. Accesses from main store (which require a symbol table lookup) are performed by special-purpose opcodes. - Damien