Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=dQbkjrobem6qBP7Qc7w9tW6YlQzV5+wnk4boVxgF8SHouW8VUSMWAK4xoC8zmQJavRkSIF/sR6aX4KlkjpBz9DHtwCcLcNfb2OUWBaMqAa0rhx+HwkabsmE3aYo8B+qUgcdjvD04TwCySA+k5gikIxtBIIwI2ODD0tG+4DSwLnE=
Message-ID: <4522B05B.4010303@gmail.com>
Date: Tue, 03 Oct 2006 19:47:55 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Recognizing lock objects
References: <4522907F.7070203@gmail.com>
 <4dd1f3f00610031033s48e47682ta2db1934cf6522ec@mail.gmail.com>
 <4522A205.2060406@pobox.com> <4522A2C7.3070808@pobox.com>
In-Reply-To: <4522A2C7.3070808@pobox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Yep, you've got it.

Regards,
Tim

Geir Magnusson Jr. wrote:
> 
> 
> Geir Magnusson Jr. wrote:
>> I don't think the goal is performance, but just being able to monitor
>> what sync blocks are hot via watching the sync objects.
> 
> What I meant to say was that it's not the performance of the lock
> objects themselves, but the overall performance of the code that uses
> it, hence looking for a better way to identify "hot" lock objects.
> 
> And therefore, I now grok why we can't have a global one. :)
> 
>>
>> geir
>>
>>
>> Weldon Washburn wrote:
>>> Tim,
>>>
>>> I suspect there may be some JVM internal lock design issues involved
>>> in what
>>> you are suggesting.  In specific, I vaguely remember a paper written by
>>> David Bacon that describes lock optimization heuristics based on the
>>> observation that most of the time, the object being locked is an
>>> instance of
>>> a "synchronized" class.
>>>
>>> Maybe it makes sense to build a microbenchmark of what you are
>>> suggesting
>>> and run it on several different JVMs?  Maybe it makes sense to prototype
>>> Java locking code in a way that VM fat/thin locks like best??
>>>
>>> I suspect that your initial goal is classlib performance only.  I'd
>>> like to
>>> see if we can expand this to JVM-wide system performance.  Otherwise
>>> we run
>>> the risk of re-optimizing the whole stack and re-opening the classlib
>>> lock
>>> design at a later date.   :(
>>>
>>>
>>>
>>>
>>>
>>> On 10/3/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>>
>>>> There are a number of places in the class library code where we create
>>>> an object solely to use as a synchronized block 'lock'.
>>>>
>>>> For example, in RandomAccessFile we define a
>>>>
>>>> private Object repositionLock = new Object();
>>>>
>>>> then in a number of methods
>>>> public int read()..
>>>>   ..
>>>>   synchronized(repositionLock) {
>>>>     ...
>>>>   }
>>>>
>>>> you get the idea.
>>>>
>>>> Using an instance of Object makes it hard to see (in profiling tools)
>>>> which lock objects are 'hot', or how often a particular lock object is
>>>> used.
>>>>
>>>> I'd like to replace the generic Object instance with a private type
>>>> just
>>>> for the purpose, like this:
>>>>
>>>>    private class RepositionLock {}
>>>>    private Object repositionLock = new RepositionLock();
>>>>
>>>> The usage would be the same, but it will then be easier to see if
>>>> RandomAccessFile$RepositionLock becomes a choke point.
>>>>
>>>> Any objections or improvements to this proposed 'pattern' and
>>>> putting it
>>>> into various places throughout the class library?
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>> -- 
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org