Re: JavaMemoryModel: Native code destroys code analysis?

From: David Detlefs - Sun Microsystems Labs BOS (detlefs@slats.East.Sun.COM)
Date: Thu Nov 11 1999 - 10:24:20 EST

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 :-)

JavaMemoryModel mailing list -

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