JavaMemoryModel: Native code destroys code analysis?

From: Bill Pugh (pugh@cs.umd.edu)
Date: Wed Nov 10 1999 - 13:21:56 EST


Thinking about the problems with native code changing final fields
got me thinking about a different problem.

I suspect there are lots of tools that analyze a program and make
decisions such as:
        Well, although this field is of type Object, the field is private
        and all the putfields in the class put a String into the field,
        so I can deduce that the field will always hold a String and inline
        virtual methods invoked on what this field references.

The problem with this is that there is no way for compilers to look
at native code, and the SetField JNI calls don't respect private
annotations.

All kinds of things, such as escape analysis, get trashed if you have
to account for unknown native code.

Reflection can have much of the same effects. With the right run-time
permissions, you can read and set private fields.

Thoughts? For people who have done these kinds of analysis, are you
confident that your analysis is correct in the presence of native
code and reflection? Is so, why?

        Bill
-------------------------------
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