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
