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