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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
