> [mailto:firstname.lastname@example.org]On Behalf Of William Pugh
> OK. First, I hope everyone will agree that nothing should be allowed
> to crash or corrupt the VM, even if a program contains unsynchronized
> access to shared data.
> - this primarily means that the system must not act on stale values
> in the object header, in the vtbl or other class data structures.
It seems to me that these sort of low-level issues depend very much on the
VM implementation and are not dependent on the Java memory model. The VM
implementation must ensure that it deals with atomicity, visibility and
ordering appropriately regardless of the language level rules. I certainly
would not expect to take Ch17 and try to make inferences about internal VM
data structure behaviour. Why are such issues being raised?
> And of course, there is the fact that much of the existing Java code
> base is broken if we don't have initialization safety.
Much of the existing Java code base is broken even with initilisation
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email email@example.com and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:14 EDT