harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [classlib] Recognizing lock objects
Date Tue, 03 Oct 2006 17:33:22 GMT

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

Weldon Washburn
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message