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:46:45 GMT
I don't think the goal is performance, but just being able to monitor 
what sync blocks are hot via watching the sync objects.

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


Mime
View raw message