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

Keith McGuigan Keith.McGuigan at Sun.COM
Wed Dec 9 07:34:20 PST 2009

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

More information about the hotspot-dev mailing list