In the Sun Labs ResearchVM, I developed an analysis to identify
(non-final) immutable private fields, which enabled an optimization
related to inlining.
Like Keith Randall, I assumed that native code using JNI obeyed access
restrictions, and that the use of reflection was well-behaved.
Two related observations:
1) the java.lang.reflect.AccessibleObject.setAccessible() methods
(two signatures) each throw SecurityException. Perhaps an
implementation that relies on reflection not allowing the
modification of an immutable field could coordinate with its
security manager to ensure that calls that could allow
immutability to be violated raise this exception.
Or, as Keith implies, dependencies could be tracked, and such a
call could require the recompilation of all methods whose previous
complications depended on the now-violated assumption.
Sure would have been nice if the concept "Accessible" had been
refined into "ReadAccessible" and "ReadWriteAccessible". Or maybe
this isn't actually necessary; the recompilation described above
could be delayed until you actually write through the accessible
field for the first time.
2) There is at least one case enshrined in the library code where the
JNI is used specifically to override access protection. The code
for handling weak references and finalizers was moved out of the
VM and into Java. I guess this is laudable; however, it takes a
process that was entirely "magic" defined by the language and VM
specs, and makes it seem like it is just normal Java code obeying
normal Java semantics. This is even almost completely true,
except for:
final class Finalizer extends FinalReference { /* Package-private; must be in
same package as the Reference
class */
/* A native method that invokes an arbitrary object's finalize method is
required since the finalize method is protected
*/
static native void invokeFinalizeMethod(Object o) throws Throwable;
By the way: the optimization that relies on "proofs" of immutability
is disabled by default in the product version :-)
Dave
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT