ThreadPoolExecutor implement question!

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ThreadPoolExecutor implement question!

yangjs
hi,all
 
when I read ThreadPoolExecutor code ,I found it's declare the mainLock use "final" ,
 
  private final ReentrantLock mainLock = new ReentrantLock();
 
many method use the lock  guarding state, use case as follow:
 
     final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            // some code
        } finally {
            mainLock.unlock();
        }
 
My question is the instance field already use "final" to mainLock,
why every method need copy mainLock reference to final  local var.
 
this puzzle me,who can tell me why ? thanks.
 
Best regards,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor implement question!

David Holmes-3
This was an optimization to work around a VM "glitch" which where the final field is loaded on each access (as a normal field would be) rather than loading it once. To avoid this it is copied to a local variable.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of yangjs
Sent: Thursday, 21 September 2006 4:30 PM
To: [hidden email]
Subject: [concurrency-interest] ThreadPoolExecutor implement question!

hi,all
 
when I read ThreadPoolExecutor code ,I found it's declare the mainLock use "final" ,
 
  private final ReentrantLock mainLock = new ReentrantLock();
 
many method use the lock  guarding state, use case as follow:
 
     final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            // some code
        } finally {
            mainLock.unlock();
        }
 
My question is the instance field already use "final" to mainLock,
why every method need copy mainLock reference to final  local var.
 
this puzzle me,who can tell me why ? thanks.
 
Best regards,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor implement question!

Hanson Char
Is such optimization only applicable to final fields, but not instance member fields in general ?  Does this mean if a final field is accessed more than once in a method, it's always faster to assign it first to a local variable ?

Hanson

On 9/21/06, David Holmes <[hidden email]> wrote:
This was an optimization to work around a VM "glitch" which where the final field is loaded on each access (as a normal field would be) rather than loading it once. To avoid this it is copied to a local variable.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of yangjs
Sent: Thursday, 21 September 2006 4:30 PM
To: [hidden email]
Subject: [concurrency-interest] ThreadPoolExecutor implement question!

hi,all
 
when I read ThreadPoolExecutor code ,I found it's declare the mainLock use "final" ,
 
  private final ReentrantLock mainLock = new ReentrantLock();
 
many method use the lock  guarding state, use case as follow:
 
     final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            // some code
        } finally {
            mainLock.unlock();
        }
 
My question is the instance field already use "final" to mainLock,
why every method need copy mainLock reference to final  local var.
 
this puzzle me,who can tell me why ? thanks.
 
Best regards,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor implement question!

yangjs
 thx,
 
  I think if it does as David said, the optimization should happend  at compile time or  VM  runtime.
 
  it is a lower level skill for application developer. is right?
 
 
 
 
 
----- Original Message -----
Sent: Thursday, September 21, 2006 4:03 PM
Subject: Re: [concurrency-interest] ThreadPoolExecutor implement question!

Is such optimization only applicable to final fields, but not instance member fields in general ?  Does this mean if a final field is accessed more than once in a method, it's always faster to assign it first to a local variable ?

Hanson

On 9/21/06, David Holmes <[hidden email]> wrote:
This was an optimization to work around a VM "glitch" which where the final field is loaded on each access (as a normal field would be) rather than loading it once. To avoid this it is copied to a local variable.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of yangjs
Sent: Thursday, 21 September 2006 4:30 PM
To: [hidden email]
Subject: [concurrency-interest] ThreadPoolExecutor implement question!

hi,all
 
when I read ThreadPoolExecutor code ,I found it's declare the mainLock use "final" ,
 
  private final ReentrantLock mainLock = new ReentrantLock();
 
many method use the lock  guarding state, use case as follow:
 
     final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            // some code
        } finally {
            mainLock.unlock();
        }
 
My question is the instance field already use "final" to mainLock,
why every method need copy mainLock reference to final  local var.
 
this puzzle me,who can tell me why ? thanks.
 
Best regards,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
<A onclick="return top.js.OpenExtLink(window,event,this)" href="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest" target=_blank>http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor implement question!

Doug Lea
In reply to this post by Hanson Char
Hanson Char wrote:
> Is such optimization only applicable to final fields, but not instance
> member fields in general ?  Does this mean if a final field is accessed
> more than once in a method, it's always faster to assign it first to a
> local variable ?
>

JVMs are generally smart enough to do this, when they are allowed to.
They are not allowed to, for example if you have
   a = somefield;
   synchronized(this) { b = somefield; ... }
According to the JMM (Java Memory Model), b cannot in general just
use the load from a.

JVMs must completely understand and enforce all the rules of the JMM.
Which they do, but sometimes too conservatively. The performance glitch
here is that JVMs don't always understand that a final field that itself
references a lock doesn't have to be reloaded across its own lock boundary,
when it is again used to perform the corresponding unlock. This
is a fairly subtle fact that escapes the attention of at least
some JVMs.

This is a micro-optimization that matters less as JVMs get smarter,
and even so, is hardly ever worth doing (which is why we don't
talk about it much) unless you are writing library code used
by millions of people where you might as well make it as fast
as you know how.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ThreadPoolExecutor implement question!

David Holmes-3
Doug writes:
> This is a micro-optimization that matters less as JVMs get smarter,
> and even so, is hardly ever worth doing (which is why we don't
> talk about it much) unless you are writing library code used
> by millions of people where you might as well make it as fast
> as you know how.

For completeness I'll mention that "caching" fields into locals can have
performance benefits in specialized contexts, such as in real-time Java. In
the RTSJ field accesses can require additional checks on both reads and
writes, so reducing that to a single read/write can be beneficial. The
optimizations in such environments are still lagging.

Cheers,
David


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest