RE: JavaMemoryModel: Legality of native code changing final field s

From: David Holmes (dholmes@dstc.edu.au)
Date: Mon Jun 11 2001 - 18:24:38 EDT


Bill Pugh wrote:
> Tim Lindholm and I checked out Sheng Liang's AW book on JNI, and in
> section 10.9, page 138, it pretty clearly states that JNI code
> changing final fields has undefined semantics that could include
> corrupting or crashing the VM.

I think you have mis-read this section. The text states:

"Native code that bypasses source-language-level access checks may have
undesirable effects on program execution. For example, an inconsistency may
be created if a native method modifies a final field after a just-in-time
(JIT) compiler has inlined access to the field."

This is a well known problem and hopefully the one thing that will prevent
the vast majority of programs from ever changing a final field (other than
System.in et al, or in deserialization) in native code. It seems apparent
that nobody foresaw this interaction.

The text then goes on to say that native code should also not modify
immutable objects as that "may lead to breakage of invariants in the Java
platform implementation". Granted the modification of a final field in a
core class may also break an invariant, but I think we are more concerned
about application classes modifying their own final fields rather than
corrupting system classes.

Additionally, this text is commentary only it is not part of the actual JNI
specification. As far as "legality" is concerned, JNI allows the
modification of final fields.

I've said this before but I'll repeat it. I don't think the JSR will have
any chance of changing JNI to prevent modifications to final fields, for a
variety of reasons. But it is also not necessary to prevent it. Use of
native code turns off all safety guarantees and so we need not be concerned
about what native code does with regard to synchronization, in general.

What we do have to consider is compiler assumptions about the values of
final fields across native method calls, but only in contexts were the JMM
defines visibility guarantees, such as some forms of construction and
presumably de-serialization (which is defacto construction but is already
crippled with respect to final fields).

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:31 EDT