Review Request: 6908267: Zero fails to unlock synchronized native methods on exception

[Tom Rodriguez]

>From what I can tell the unlocking for synchronized methods is always performed in Interpreter::_remove_activation_entry which tears down an interpreter frame in the event of an exception.  We get there through InterpreterRuntime::exception_handler_for_exception.  I think the other cppInterpeter's have the same problem as zero.  In their case I believe the unlock code should be moved above the check for a pending exception though I'm unsure how that interacts with the notify_method_exit logic for JVMTI.

tom

On Dec 8, 2009, at 3:43 PM, David Holmes - Sun Microsystems wrote:

> Hi Gary,
> 
> Gary Benson said the following on 12/09/09 00:58:
>> Hi all,
>> If a synchronized native method throws an exception, Zero does not
>> unlock it.  This leaves the receiver/mirror locked, with a stale
>> monitor, which can cause the VM will crash at some unspecified time
>> in the future.  This webrev fixes it.
>>  http://cr.openjdk.java.net/~gbenson/zero-fix-6908267/
> 
> Your original code indicates that it emulated the template interpreter by not unlocking upon an exception. Have you determined why this was wrong? The comments in the sparc and x86 interpreter have me concerned eg:
> 
> // With c++ interpreter we just leave it pending caller will do the correct thing. However...
> // Like x86 we ignore the result of the native call and leave the method locked. This
>    // seems wrong to leave things locked.
> 
> Though an earlier comment states the exception handling will handle unlocking.
> 
> Just curious ...
> 
> David Holmes