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
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 wa
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
will, by coincidence,
> be very roughly the same number of bytes in memory).
>
> Regards,
> Tim
>
>
>>> -Original Message-
>>> From: Tim Ellison [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, October 04, 2006 6:30 AM
>>> To: harmon
lison [mailto:[EMAIL PROTECTED]
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
m Ellison [mailto:[EMAIL PROTECTED]
>> 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 na
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:[EMAIL PROTECTED]
> Sent: Wednesday, October 04, 2006 6:30 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classl
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 "FOO
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
>
+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
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 t
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
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
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
private class RepositionLock {}
private Object repositionLock = new Reposition
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
>
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,
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
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
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()..
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(repo
21 matches
Mail list logo
