> Standing at the view point of JVM, which actions
> do getfield/putfield correspond to, use/assign or load/store?
> Java specification (Chapter 17) doesn't state that explicitly. In Alex
> Gontmakher and Assaf Schuster's paper "Java consistency: nonoperational
> characterizations for Java memory behavior", getfield/putfield were
> interpreted to load/store. In Puph's paper "Fixing the Java
> Memory Model", getfield/putfield were interpreted to use/assign.
> However, Puph also supports that Java requires coherence.
Another good reason that chapter 17 is incomprehensible. My understanding
of it is that use and assign are equivalent to getfield and putfield.
Of course, I may be biased... To quote:
"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.
An assign action (by a thread) transfers a value from the thread's
execution engine into the thread's working copy of a variable. This action
is performed whenever a thread executes a virtual machine instruction that
assigns to a variable."
By virtual machine instruction, they mean getfield/putfield (among
others). Coherence is implied because of the requirement that assignments
to variables appear in memory in the order in which a thread performs
them. If it is a proof that this is true you are looking for, it is in
(flips through his notes) Non-operational characterizations for Java
memory behavior, by Gontmakher and Schuster, which is Technion tech report
Loads, stores, reads and writes are all memory consistency operations
which occur only as a side effect of JVM instructions: either through
explicit synchronization or through the rules described in chapter 17.
> Another question also confused me: what is thread working memory? If
> getfield/putfield correspond to load/store, thread stack can be considered
> as thread working memory. if getfield/putfield correspond to use/assign,
> thread stack is a part of thread engine.
The concept of a stack is orthogonal to these issues, because the values
in the stack don't directly represent a variable's contents. They may
represent values read from a variable, but not its contents. So, if I
read the value 4 from variable x into the stack, what I have in the stack
is the value 4, not the variable x. A thread is aware of the values in
its own stack without having to perform any memory consistency
operations; from an architecture standpoint, this is because the thread
is the only thing writing to the stack.
In any case, main memory, working memory and execution engine are
abstractions, not functions of the architecture. Thread working memory
contains the most up-to-date copy of all variables that a thread knows
about. The value of a variable x in working memory can be set in two
ways: by the thread's setting x with an assign, or the thread's performing
a load instruction to get the latest value of x from main memory. You can
think of working memory as a local cache on which operations are performed
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT