On 1/26/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I think we have a choice here. The VM spec seems to hint at what we should do, but not require it :The VM spec 8.13 : "Normally, a compiler for the Java programming language ensures that the lock operation implemented by a monitorenter instruction executed prior to the execution of the body of the synchronized statement is matched by an unlock operation implemented by a monitorexit instruction whenever the synchronized statement completes, whether completion is normal or abrupt." Notice "normally", which means, we can't expect it. It goes further : "Although a compiler for the Java programming language normally guarantees structured use of locks (see Section 7.14, "Synchronization"), there is no assurance that all code submitted to the Java virtual machine will obey this property. Implementations of the Java virtual machine are permitted but not required to enforce both of the following two rules guaranteeing structured locking. Let T be a thread and L be a lock. Then: 1. The number of lock operations performed by T on L during a method invocation must equal the number of unlock operations performed by T on L during the method invocation whether the method invocation completes normally or abruptly. 2. At no point during a method invocation may the number of unlock operations performed by T on L since the method invocation exceed the number of lock operations performed by T on L since the method invocation. In less formal terms, during a method invocation every unlock operation on L must match some preceding lock operation on L." My read is that we can enforce this if we want to, but my sense is that this would be a nice to have - a bit of polish - not a must have, as we can depend upon compilers to do the right thing. However, it would be cute if we could detect such a thing and in a debug mode, emit a message to help people figure out why their code doesn't run right :)
A VM thread should unlock all the held locks before it exits. The example code given above is incomplete, because the exeception need certain handling in JVM that it doesn't show. If the exception is uncaught by any frames on the stack, the thread will pop all the frames and release all its held locks before exiting. Otherwise, the exception catch or finally handler should take care of the held locks. If the exception is uncaught and the lock's owning thread exits, the waiting thread for the same lock can acquire it without deadlock. If the owning thread doesn't exit, no one knows when it will release this lock. It can hold this lock again since the lock supports recursion. I guess we can't say a deadlock happens for this situation. We can say the waiting thread looks like starved for it, but it might be intended behavior. So probably this example code doesn't expose a real issue. Thanks, xiaofeng
geir On Jan 26, 2007, at 5:02 AM, Shipilov, Alexander D wrote: > Thank you for the answer. > Not, sure not reject the method :). > I think that it will be nice if VM release all locks entered by > thread > that threw exception. > But if it's impossible, I nothing can be say against closing this > JIRA. > > Thanks, > Alexander Shipilov > >> -----Original Message----- >> From: Rana Dasgupta [mailto:[EMAIL PROTECTED] >> Sent: Friday, January 26, 2007 1:35 AM >> To: [email protected] >> Subject: Re: [drlvm] If method throws exception after >> monitorenter, JIT >> does not release the lock >> >> I am not sure if this is a problem. Would you expect the jit to > generate >> the >> finally code, reject the method, or what? >> >> On 1/25/07, Shipilov, Alexander D <[EMAIL PROTECTED]> > wrote: >>> >>> Hello, folks, >>> >>> Could you, please clarify one issue. >>> The problem has described in JIRA >>> https://issues.apache.org/jira/browse/HARMONY-2504. >>> >>> Thread makes monitorenter, and throws exception (NPE) to the output. >>> JASMIN code: >>> .method public run()V >>> .limit stack 3 >>> .limit locals 3 >>> >>> getstatic Test/testField Ljava/lang/Object; >>> monitorenter >>> >>> new java/lang/NullPointerException >>> dup >>> invokespecial java/lang/NullPointerException/<init>()V >>> athrow >>> >>> getstatic Test/testField Ljava/lang/Object; >>> monitorexit >>> >>> return >>> .end method >>> >>> Then other thread tries to get a lock. Deadlock occurs on Harmony. >>> Does this behavior is correct? >>> >>> Thanks, >>> Alexander Shipilov >>>
