Jerry Schwarz wrote:
> Specifically they all use writeJNIFinal except
>
> A. When they are writing the field of an object whose
> constructor has not yet returned.
>
> B. During some (yet to be determined) times associated with
> deserialization.
>
> Granted B is ugly, but as has been noted previously some
> exceptions need to be made for serialization.
I can't comment on the formal side of things but I agree with Jerry's
position here. We need to abstractly define a "construction process" - which
covers the constructor chain as well as the deserialization process - during
which JNI writes are accounted for correctly.
I don't see any need to change the de-serialization process/code (nor do I
think we would be able to), but we will need to define the appropriate
places where visibility needs to be maintained and where finality can't be
taken for granted. Given deserialization is I/O based anyway, a simple
memory barrier at the "end" should not overtly impact performance.
Of course, we still need to watch for escaping objects and I'm not sure how
the other complexities of deserialization (readResolve and object
validation) may impact things.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT