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

[Tom Rodriguez]

Methods with the synchronized modifier don't use bytecodes to implement their unlocking so it's up to the JVM itself to perform the needed locking and unlocking.  Client compiled frames do implement the proper unlocking.  Previously this was done in the exception handler entry point for the compiled frame in a fairly explicit manner but in 1.6 this was moved up into the IR with a synthetic exception handler to perform the unlocking.  Search for sync_handler in c1_GraphBuilder.cpp.

tom

On Dec 9, 2009, at 7:34 AM, Keith McGuigan wrote:

> Tom Rodriguez wrote:
>> 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.
> 
> Doesn't the bytecode for synchronized methods typically (always?) have a  catch-all exception handler that performs the monitorexit and then rethrows (in the case of an uncaught exception)?  And if that's the case, do we really need the unlocking logic in remove_activation_entry?  We don't have similar logic for client-compiled frames.
> 
> --
> - Keith