Re: JavaMemoryModel: Serialization and final fields

From: Doug Lea (
Date: Thu Aug 26 1999 - 07:01:30 EDT

> * 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
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 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 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 315-341-2688 FAX:315-341-5424  

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT