harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] If method throws exception after monitorenter, JIT does not release the lock
Date Fri, 26 Jan 2007 12:41:33 GMT
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 :)

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
>>>


Mime
View raw message