Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=EDZlt6mGqS0SqPi0djAHQ/XcMKQEHtGpRCwF+2RKgJGtLzwFNywe3YLwmWc9/JySPP5XcPfKda31FsbV+SMOfrL4GsA1dNd95ZihAVeVrnqqJGmLlAJsPP7T33C2QyRd1f5XIjfxE7sP8T/CMBntcc8O/p3XeBg/lcDb8UIcksY=
Message-ID: <9623c9a50701260508me1a75fahf2631f5fb584d396@mail.gmail.com>
Date: Fri, 26 Jan 2007 21:08:20 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] If method throws exception after monitorenter,
 JIT does not release the lock
In-Reply-To: <70F15DF7-3743-439D-B716-6A4672B1746D@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2A786EB15713B544AB79607529273B047FADE5@mssmsx411>
	 <70F15DF7-3743-439D-B716-6A4672B1746D@pobox.com>

On 1/26/07, Geir Magnusson Jr. <geir@pobox.com> 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:rdasgupt@gmail.com]
> >> Sent: Friday, January 26, 2007 1:35 AM
> >> To: dev@harmony.apache.org
> >> 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 <alexander.d.shipilov@intel.com>
> > 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
> >>>
>
>