Tom Tromey wrote:
"Bryce" == Bryce McKinlay <[EMAIL PROTECTED]> writes:
Bryce> Certainly, bytecode isn't allowed to do this kind of thing, but I'm
Bryce> not sure if the structured locking rules in the VM spec are meant to
Bryce> apply to native code. For example, wait() would be impossible to
Bryce> implement if this were the case, wouldn't it?
I agree with your main point, that it isn't clear that this restriction is meant to apply to native code. I suppose I would expect to see a note in the JNI spec about this -- except that the JNI specification is in general not that precise. (As to wait(), I think one could plausibly argue that it is a special case, part of the VM.)
The problem exists when native code does things that are visible to non-native code, like locking objects. If it doesn't touch the Java heap then I would say that yes, you can do whatever you want.
As a trivial example: it is possible to define native methods that do the equivalent of MONITORENTER and MONITOREXIT, so that you can lock and unlock things without using synchronized methods or blocks. If these are allowed to be unstructured, simply because they are native, then it seems completely pointless to let the VM enforce this rule in the first place, since the programmer or even bytecode compiler can now easily circumvent it.
http://developer.novell.com/research/devnotes/1999/january/03/04.htm
Chris
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
