At 1:46 PM +1000 7/1/99, David Holmes wrote:
> > [mailto:owner-javamemorymodel@cs.umd.edu]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.
>
>Of course.
>
> > - 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?
Because the fundamental issues raised by safe virtual method dispatch
are the same as initialization safety. We have to come up with a
mechanism to handle the first. That same mechanism could be used to
implement initialization safety, if we decide to add initialization
safety to the spec.
So it isn't a question of adding "safe virtual method dispatch" to
the spec. It is figuring out implementation strategies for handling
it, and whether they could be used for initialization safety.
Bill
-------------------------------
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 majordomo@cs.umd.edu 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