You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/10/03 18:31:59 UTC
[classlib] Recognizing lock objects
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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison 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();
Why "RepositionLock"? (curious about origin of the name)
>
> 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?
I like it. But, any benefit to having a general class
o.a.h.whatever.LockObject rather than class private?
geir
---------------------------------------------------------------------
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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
FWIW I counted 35 cases in the entire class library.
Tim
Tim Ellison wrote:
> Nathan Beyer wrote:
>> There may be value in doing this, but what's the increase in class file
>> overhead? Every new class that gets created for these locks ends up as
>> another class file that has to be stored (takes up drive space) and has to
>> be loaded (takes up memory in the class loader). Ever additional class file
>> takes up at least 1K of space on Windows.
>>
>> How many of these locks are we talking about?
>
> I haven't counted, but I'd guess 10's rather than 100's based on what I
> have found so far.
>
> Each .class files created take up about 360 bytes in the JAR file. The
> size in memory is obviously dependent upon the VM implementation but I
> don't expect it to be onerous (in the IBM VME it will, by coincidence,
> be very roughly the same number of bytes in memory).
>
> Regards,
> Tim
>
>
>>> -----Original Message-----
>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>> Sent: Wednesday, October 04, 2006 6:30 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib] Recognizing lock objects
>>>
>>> Mikhail Fursov wrote:
>>>> Another variant is to use anonymous class without the name:
>>>> Object lock = new Object(){};
>>>>
>>>> But the name by itself (RepositionLock) serves like a comment.
>>> Yep -- I'm inclined to keep the meaningful name.
>>>
>>> Reagrds,
>>> Tim
>>>
>>>
>>>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>>>> private class RepositionLock {}
>>>>> private Object repositionLock = new RepositionLock();
>>>>>
>>>>>
>>> --
>>>
>>> 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
>>
>>
>
--
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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Oh, for a #define :)
Tim Ellison wrote:
> Nathan Beyer wrote:
>> There may be value in doing this, but what's the increase in class file
>> overhead? Every new class that gets created for these locks ends up as
>> another class file that has to be stored (takes up drive space) and has to
>> be loaded (takes up memory in the class loader). Ever additional class file
>> takes up at least 1K of space on Windows.
>>
>> How many of these locks are we talking about?
>
> I haven't counted, but I'd guess 10's rather than 100's based on what I
> have found so far.
>
> Each .class files created take up about 360 bytes in the JAR file. The
> size in memory is obviously dependent upon the VM implementation but I
> don't expect it to be onerous (in the IBM VME it will, by coincidence,
> be very roughly the same number of bytes in memory).
>
> Regards,
> Tim
>
>
>>> -----Original Message-----
>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>> Sent: Wednesday, October 04, 2006 6:30 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib] Recognizing lock objects
>>>
>>> Mikhail Fursov wrote:
>>>> Another variant is to use anonymous class without the name:
>>>> Object lock = new Object(){};
>>>>
>>>> But the name by itself (RepositionLock) serves like a comment.
>>> Yep -- I'm inclined to keep the meaningful name.
>>>
>>> Reagrds,
>>> Tim
>>>
>>>
>>>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>>>> private class RepositionLock {}
>>>>> private Object repositionLock = new RepositionLock();
>>>>>
>>>>>
>>> --
>>>
>>> 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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> There may be value in doing this, but what's the increase in class file
> overhead? Every new class that gets created for these locks ends up as
> another class file that has to be stored (takes up drive space) and has to
> be loaded (takes up memory in the class loader). Ever additional class file
> takes up at least 1K of space on Windows.
>
> How many of these locks are we talking about?
I haven't counted, but I'd guess 10's rather than 100's based on what I
have found so far.
Each .class files created take up about 360 bytes in the JAR file. The
size in memory is obviously dependent upon the VM implementation but I
don't expect it to be onerous (in the IBM VME it will, by coincidence,
be very roughly the same number of bytes in memory).
Regards,
Tim
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>> Sent: Wednesday, October 04, 2006 6:30 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] Recognizing lock objects
>>
>> Mikhail Fursov wrote:
>>> Another variant is to use anonymous class without the name:
>>> Object lock = new Object(){};
>>>
>>> But the name by itself (RepositionLock) serves like a comment.
>> Yep -- I'm inclined to keep the meaningful name.
>>
>> Reagrds,
>> Tim
>>
>>
>>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>>> private class RepositionLock {}
>>>> private Object repositionLock = new RepositionLock();
>>>>
>>>>
>>>
>> --
>>
>> 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
>
>
--
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
RE: [classlib] Recognizing lock objects
Posted by Nathan Beyer <nb...@gmail.com>.
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up drive space) and has to
be loaded (takes up memory in the class loader). Ever additional class file
takes up at least 1K of space on Windows.
How many of these locks are we talking about?
-Nathan
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Wednesday, October 04, 2006 6:30 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] Recognizing lock objects
>
> Mikhail Fursov wrote:
> > Another variant is to use anonymous class without the name:
> > Object lock = new Object(){};
> >
> > But the name by itself (RepositionLock) serves like a comment.
>
> Yep -- I'm inclined to keep the meaningful name.
>
> Reagrds,
> Tim
>
>
> > On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
> >>
> >> private class RepositionLock {}
> >> private Object repositionLock = new RepositionLock();
> >>
> >>
> >
> >
>
> --
>
> 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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Fursov wrote:
> Another variant is to use anonymous class without the name:
> Object lock = new Object(){};
>
> But the name by itself (RepositionLock) serves like a comment.
Yep -- I'm inclined to keep the meaningful name.
Reagrds,
Tim
> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> private class RepositionLock {}
>> private Object repositionLock = new RepositionLock();
>>
>>
>
>
--
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
Re: [classlib] Recognizing lock objects
Posted by Endre Stølsvik <En...@Stolsvik.com>.
Tim Ellison wrote:
> Endre Stølsvik wrote:
>
>> What about an marker interface, or common ancestor class? Just to mark it
>> as being of this type of usage? Would do a lot of good, I recon, to be
>> able to trace/track such usages..? (Re java.util.EventListener, "A tagging
>> interface.. ")
>>
>
> How would that help? The goal was to make them all different so we can
> recognise them.
>
>
Then you'd get best of both worlds - different classes (thus them being
easy to look for), but with a common ancestor, so that the question of
"how many of these are there" would be answered instantly.
Regards,
Endre
---------------------------------------------------------------------
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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
Endre Stølsvik wrote:
> What about an marker interface, or common ancestor class? Just to mark it
> as being of this type of usage? Would do a lot of good, I recon, to be
> able to trace/track such usages..? (Re java.util.EventListener, "A tagging
> interface.. ")
How would that help? The goal was to make them all different so we can
recognise them.
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
Re: [classlib] Recognizing lock objects
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Wed, 4 Oct 2006, Geir Magnusson Jr. wrote:
|
|
| Tim Ellison wrote:
| > Geir Magnusson Jr. wrote:
| >> +1
| >>
| >> BTW, why call it "RepositionLock"?
| >
| > That was just an example taken from the class I was looking at, I've
| > called them different names depending upon the inst var name.
|
| Oh, thanks.
|
| It might not be a bad idea to adopt a common pattern like "FOOSyncLock"
| - might make it easier to search for hotspots in a profiler...
Just stumbled upon this thread while organizing my email..!
What about an marker interface, or common ancestor class? Just to mark it
as being of this type of usage? Would do a lot of good, I recon, to be
able to trace/track such usages..? (Re java.util.EventListener, "A tagging
interface.. ")
Regards,
Endre.
---------------------------------------------------------------------
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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> +1
>>
>> BTW, why call it "RepositionLock"?
>
> That was just an example taken from the class I was looking at, I've
> called them different names depending upon the inst var name.
Oh, thanks.
It might not be a bad idea to adopt a common pattern like "FOOSyncLock"
- might make it easier to search for hotspots in a profiler...
geir
>
> Tim
>
>> Tim Ellison wrote:
>>> BTW, as I go through the code looking at the occurrences of 'new
>>> Object()' and determining if they are used simply for their locks, I
>>> figured we also need a way to record the check has been done.
>>>
>>> So, if there is a 'new Object()' that is not simply a lock object (and
>>> therefore named as we agreed) I'll mark it on the same line as
>>> // $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
>>>
>>> Regards,
>>> Tim
>>>
>>> Mikhail Fursov wrote:
>>>> Another variant is to use anonymous class without the name:
>>>> Object lock = new Object(){};
>>>>
>>>> But the name by itself (RepositionLock) serves like a comment.
>>>>
>>>>
>>>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>>>> private class RepositionLock {}
>>>>> private Object repositionLock = new RepositionLock();
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> 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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> +1
>
> BTW, why call it "RepositionLock"?
That was just an example taken from the class I was looking at, I've
called them different names depending upon the inst var name.
Tim
> Tim Ellison wrote:
>> BTW, as I go through the code looking at the occurrences of 'new
>> Object()' and determining if they are used simply for their locks, I
>> figured we also need a way to record the check has been done.
>>
>> So, if there is a 'new Object()' that is not simply a lock object (and
>> therefore named as we agreed) I'll mark it on the same line as
>> // $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
>>
>> Regards,
>> Tim
>>
>> Mikhail Fursov wrote:
>>> Another variant is to use anonymous class without the name:
>>> Object lock = new Object(){};
>>>
>>> But the name by itself (RepositionLock) serves like a comment.
>>>
>>>
>>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>>> private class RepositionLock {}
>>>> private Object repositionLock = new RepositionLock();
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+1
BTW, why call it "RepositionLock"?
Tim Ellison wrote:
> BTW, as I go through the code looking at the occurrences of 'new
> Object()' and determining if they are used simply for their locks, I
> figured we also need a way to record the check has been done.
>
> So, if there is a 'new Object()' that is not simply a lock object (and
> therefore named as we agreed) I'll mark it on the same line as
> // $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
>
> Regards,
> Tim
>
> Mikhail Fursov wrote:
>> Another variant is to use anonymous class without the name:
>> Object lock = new Object(){};
>>
>> But the name by itself (RepositionLock) serves like a comment.
>>
>>
>> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>> private class RepositionLock {}
>>> private Object repositionLock = new RepositionLock();
>>>
>>>
>>
>
---------------------------------------------------------------------
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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
Anton Luht wrote:
> Hello,
>
> Maybe it's better to mark 'locking' objects with something like
> //$LOCK-1$ ? New Object() can be created for many purposes - I'm not
> sure what percent is used for locks - 10 or 90.
If it is just used for locking I'm changing the type, so there will no
need for the lock comment too.
> Another suggestion: use
>
> new Object() {
> public String toString() {
> return "something that contains some locking keyword";
> }
> }
That doesn't help distinguish them so easily, e.g. TI-based tools.
Regards,
Tim
> On 10/4/06, Tim Ellison <t....@gmail.com> wrote:
>> BTW, as I go through the code looking at the occurrences of 'new
>> Object()' and determining if they are used simply for their locks, I
>> figured we also need a way to record the check has been done.
>>
>> So, if there is a 'new Object()' that is not simply a lock object (and
>> therefore named as we agreed) I'll mark it on the same line as
>> // $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
>>
>> Regards,
>> Tim
>>
>> Mikhail Fursov wrote:
>> > Another variant is to use anonymous class without the name:
>> > Object lock = new Object(){};
>> >
>> > But the name by itself (RepositionLock) serves like a comment.
>> >
>> >
>> > On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>> >>
>> >> private class RepositionLock {}
>> >> private Object repositionLock = new RepositionLock();
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> 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
>>
>>
>
>
--
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
Re: [classlib] Recognizing lock objects
Posted by Anton Luht <an...@gmail.com>.
Hello,
Maybe it's better to mark 'locking' objects with something like
//$LOCK-1$ ? New Object() can be created for many purposes - I'm not
sure what percent is used for locks - 10 or 90.
Another suggestion: use
new Object() {
public String toString() {
return "something that contains some locking keyword";
}
}
On 10/4/06, Tim Ellison <t....@gmail.com> wrote:
> BTW, as I go through the code looking at the occurrences of 'new
> Object()' and determining if they are used simply for their locks, I
> figured we also need a way to record the check has been done.
>
> So, if there is a 'new Object()' that is not simply a lock object (and
> therefore named as we agreed) I'll mark it on the same line as
> // $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
>
> Regards,
> Tim
>
> Mikhail Fursov wrote:
> > Another variant is to use anonymous class without the name:
> > Object lock = new Object(){};
> >
> > But the name by itself (RepositionLock) serves like a comment.
> >
> >
> > On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
> >>
> >> private class RepositionLock {}
> >> private Object repositionLock = new RepositionLock();
> >>
> >>
> >
> >
>
> --
>
> 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
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
BTW, as I go through the code looking at the occurrences of 'new
Object()' and determining if they are used simply for their locks, I
figured we also need a way to record the check has been done.
So, if there is a 'new Object()' that is not simply a lock object (and
therefore named as we agreed) I'll mark it on the same line as
// $NON-LOCK-1$ so we can easily grep for divergences from the pattern.
Regards,
Tim
Mikhail Fursov wrote:
> Another variant is to use anonymous class without the name:
> Object lock = new Object(){};
>
> But the name by itself (RepositionLock) serves like a comment.
>
>
> On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> private class RepositionLock {}
>> private Object repositionLock = new RepositionLock();
>>
>>
>
>
--
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
Re: [classlib] Recognizing lock objects
Posted by Mikhail Fursov <mi...@gmail.com>.
Another variant is to use anonymous class without the name:
Object lock = new Object(){};
But the name by itself (RepositionLock) serves like a comment.
On 10/3/06, Tim Ellison <t....@gmail.com> wrote:
>
> private class RepositionLock {}
> private Object repositionLock = new RepositionLock();
>
>
--
Mikhail Fursov
Re: [classlib] Recognizing lock objects
Posted by Tim Ellison <t....@gmail.com>.
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....@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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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....@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
Re: [classlib] Recognizing lock objects
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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....@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
Re: [classlib] Recognizing lock objects
Posted by Weldon Washburn <we...@gmail.com>.
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....@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