Re: Unstructured locking bug

[Chris Pickett]

Chris Pickett wrote:
> Tom Tromey wrote:
>
> > > > > > > "Bryce" == Bryce McKinlay <address@hidden> 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