[concurrency-interest] Stupid Question

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 13 08:28:13 EST 2013


The additional memory requirements to track all of that are probably non
trivial for large apps.  It would also have track this across unsafe calls,
reflection, class loading (newly loaded classes may modify things), etc.
Seems very expensive (implementation and perf wise) for probably very
little (if any) perf gain.

Sent from my phone
On Feb 12, 2013 6:17 PM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
wrote:

>  Currently, JIT's visibility is as far as it can inline.  It can't see
> any further than that.  Couldn't JIT keep notes on the methods for whether
> (1) if parameters or the return value escape, (2) which fields are
> modified, (3) anything else useful for cross method optimization?  With
> these notes, JIT wouldn't have to inline the entire method tree to be able
> to see that the final lock field isn't modified.
>
> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Architect |
> 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>  On 2/12/2013 3:26 PM, Zhong Yu wrote:
>
> On Tue, Feb 12, 2013 at 3:21 PM, Doug Lea <dl at cs.oswego.edu> <dl at cs.oswego.edu> wrote:
>
>  On 02/12/13 15:41, javamann at cox.net wrote:
>
>
> Stupid question time. While going through the code for an ArrayBlockQueue
> I came across numerous instances where the instance 'lock' is copied to a
> variable in a Method. I know there is a reason for this, I just don't know
> what it is.
>
>
>
> It's ultimately due to the fundamental mismatch between memory models
> and OOP :-)
>
> Just about every method in all of j.u.c adopts the policy of
> reading fields as locals whenever a value is used more than once.
> This way you are sure which value applies when.
> This is not often pretty, but is easier to visually verify.
>
> The surprising case is doing this even for "final" fields.
> This is because JVMs are not always smart enough to exploit
> the fine points of the JMM and not reload read final
> values, as they would otherwise need to do across the
> volatile accesses entailed in locking. Some JVMs are smarter
> than they used to be about this, but still not always
> smart enough.
>
>
> (Forget reflection/Unsafe, only consider typical JMM actions) Can JVM
> always cache the value of a final field? What if `this` was leaked
> before constructor exit? And if the 1st read sees a non-null value,
> can that value then be cached safely?
>
> Zhong Yu
>
>
>
>
> -Doug
>
>
>
>
>
>  Thanks
>
> -Pete
>
>      public int remainingCapacity() {
>          final ReentrantLock lock = this.lock;
>          lock.lock();
>          try {
>              return items.length - count;
>          } finally {
>              lock.unlock();
>          }
>      }
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>  _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/ee8a63b9/attachment-0001.html>


More information about the Concurrency-interest mailing list