Re: Unstructured locking bug

[Chris Pickett]

Chris Gray wrote:
> On Monday 14 March 2005 22:44, Chris Pickett wrote:
> > http://developer.novell.com/research/devnotes/1999/january/03/04.htm
>
>
> I wouldn't rely too much on that document: for example it states that "there 
> is no overhead of creating a semaphore, since all Java objects have a monitor 
> associated with them by default", which is simply false - most VMs will only 
> create such a monitor when it is actually needed.

I realize this; it was just a quick example of fairly ungood JNI code.

> It's true that JNI can be used to create unbalanced monitor operations, which 
> will clearly upset any VM which tries to take advantage of the fact that 
> normally monitor operations will always be balanced. My first reaction is 
> that the VM doesn't have to be able to deal with such cases - it's just 
> another example of how JNI can be used to shoot yourself in the foot. The 
> code example in the cited document which "cannot be written using 
> synchronized directive without significant code reorganization" is, in my 
> view, in urgent need of such reorganisation - it has "disaster waiting to 
> happen" written all over it.

Again, I'm not citing that link as a good example :)  Rather something 
trivial that you'd think the VM might want to prevent (if it were abused 
to do unstructured locking).  The question is not whether the VM has to 
deal with it, but whether the VM is permitted to deal with it (and 
potentially optimize around it).

I guess some test cases on Sun's VM's would settle this question, as 
they are considered by many to be reference implementations.  The JNI 
functions in that link should be enough to test quickly what Sun does 
w.r.t. to structured locking and native code.

Feel free Etienne... :)

Chris