> Consider a static field Foo.x of type Object. In thread 1, you invoke
> Foo.x.toString(). Foo.x might reference an object of a class that has
> been loaded since the last time thread 1 did a memory barrier. So you
> can't easily tell if the vtbl entries are guaranteed to be valid.
Right - sorry about that half-baked scheme.
The point being made (which I failed to pick up) is that, just as
stale/garbage values for Java level fields could be read, so too
stale/garbage values for 'C' level object data could be read. Both need to
be fixed. Though I'd argue that the latter needs to be fixed even if we
decide the former need not - the VM should never crash due to an
application error. On the other hand if the VM is fixed then the Java level
fix will probably occur as a natural consequence.
David
-------------------------------
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