RE: JavaMemoryModel: Native methods and Final fields

From: David Holmes (dholmes@dstc.edu.au)
Date: Sun Feb 25 2001 - 18:00:11 EST


Bill Pugh wrote:
> If there were idioms that were being used all the time in production
> codes, I think they should have well defined semantics. So if lots of
> code is using native methods to change final fields, we need to
> define the semantics of doing so.

I don't agree. If native code is modifying final fields then the "final"
field is in fact a normal mutable field (except that it can't be modified at
the Java level) and must be protected (at both the native and Java levels)
using synchronization. I also sincerely hope that this is not done a lot in
practice - if it were I would have expected to see a lot more reported
problems similar to those experienced with the System fields.

> We also need to provide work-arounds for things like serialization.

Agreed - serialization is a special case. The serialization process must be
treated similarly to the construction process, with insertion of necessary
memory barriers by the end of that process. Given the overhead of
deserialization itself, general memory barriers may not be out of the
question in order to simplify things. If custom deserialization uses native
code to re-assign final's (because they can't be re-assigned at the Java
level) then those changes must be visible at the end of deserialization (and
of course we have the usual possibility of letting references escape, just
as with construction).
 
> I would have no objection to providing a native method that would
> allocate a instance of a class and then set all the fields of the
> object (including final fields), without calling the constructor. Of
> course, there are severe security implications of such a method,
> which is why the method is only accessible from native code. I
> believe that this method for constructing objects could be used to
> implement (de-)serialization.

If the method is used to implement de-serialization then it is addressed
above. If the method is a special form of factory method then I disagree -
the native code has stepped out of the bounds of what is "reasonable" for
native code to do to "final" fields and so must employ explicit
synchronization. That said, I'm still trying to ascertain exactly what
implications the new semantics have for writing factory methods in the
general case - whether Java or native.
 
Cheers,
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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