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: [classlib] Recognizing lock objects
Date Tue, 03 Oct 2006 17:49:59 GMT


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


Mime
View raw message