At 7:07 PM +0200 3/27/01, Assaf Schuster wrote:
>Indeed, this is an important question that was not addressed explicitly
>in the original spec. Note, however that your question has a more broader
>context:
>
> < How will all vendors in the world manufacture compliant >
> < JVMs when they have no spec for its memory model??? >
>
>BTW, to the best of my knowledge, even the newly proposed memory
>model by Pugh is missing explicit definition for the JVM level.
Actually, our spec is defined at the JVM level, as im the Java-CRF paper
From section 7.1 of our paper:
>An operation corresponds to one JVM opcode. A getfield, getstatic
>or array load opcode corresponds to a Read. A putfield, putstatic
>or array store opcode corresponds to a Write. A monitorenter opcode
>corresponds to a Lock, and a monitorexit opcode
>corresponds to an Unlock.
The place where we are not formal is in the definition of the
semantics of Java source programs:
>In this paper, we concern ourselves with the semantics
>of the Java virtual machine \cite{JVMS}. While defining
>a semantics for Java source programs is important,
>there are many issues that arise only in the JVM
>that also need to be resolved.
>Informally, the semantics
>of Java source programs is understood to be defined
>by their straightforward translation into classfiles,
>and then by interpreting the classfiles using the JVM semantics.
As to the meaning of use/assign/load/store in Chapter 17 of the JLS,
it is irrelevant. All of the major players in revising the JMM agree
that chapter 17 of the JLS is not a correct or desirable
specification of a Java memory model. The challenge is to come up
with a new one that matches existing use as much as possible while
incorporating other desirable features. There is no longer any
requirement or need to interpret Chapter 17.
-------------------------------
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