> * Say that in general, it is acceptable to have native code change
> final fields.
Or merely say that no memory-based guarantees of any kind can be made
about final fields that are modified by native code. Which seems like
an intrinsically true statement that ought to be there anyway.
Again, VM builders who need to simultanously obey rules for System.in
etc and prevent surprises for programmers do have the last-resort
global-barrier option available.
I don't see this last resort as too horrible in these cases since VMs
on systems where this matters need global barriers for GC anyway. So a
good VM will probably somehow tie both System.in initialization and
deserialization mechanics with GC system.
I don't know what to think about clone() though. Luckily it is so
broken that people don't use it much, but still, it is a much worse
problem than deserialization or System.in since the global-barrier
solution seems way too heavy there. (On the other hand, horrible
performance on multiprocessors would add just one more reason not to
use it.)
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT