[concurrency-interest] Stupid Question

Tomasz Kowalczewski tomasz.kowalczewski at gmail.com
Wed Feb 13 06:41:28 EST 2013


Hi,

AFAIK it's not about application assumption that is broken. It's JVM
assumption that lead to all sorts of optimizations like constant
propagation. Changing final variable will invalidate these assumptions
and C2 compiled and optimized code will be executing with old value of
the "final" field. This means that all final-modifying code would
break JVM assumptions (while not necessarily application logic).

e.g. System.out is final static and initially null. Yet you can set it
using System::setOut.
Better way to go with "almost" final vlaues is one described by Remi
in http://www.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field

On Wed, Feb 13, 2013 at 12:28 PM, oleksandr otenko
<oleksandr.otenko at oracle.com> wrote:
> I look at it simpler.
>
> If the final-modifying code breaks the application's assumption that the
> field is final, then the final-modifying code has the problem.
>
> If the final-modifying code guarantees the application's assumption that the
> field looks final, then there is no need to distinguish the case that it may
> be modified by some external means.
>
>
> Alex
>
>
>
> On 13/02/2013 11:04, Nitsan Wakart wrote:
>
> See this :
> http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
> And the follow up:
> http://www.azulsystems.com/blog/cliff/2011-10-27-final-fields-part-2
> Final fields are not treated as final because sometimes (as in: popular use
> case you can't ignore) they are not...
>
>
> ________________________________
> From: oleksandr otenko <oleksandr.otenko at oracle.com>
> To: concurrency-interest at cs.oswego.edu
> Sent: Wednesday, February 13, 2013 10:45 AM
> Subject: Re: [concurrency-interest] Stupid Question
>
> I don't get this. Why have a final, if you need to keep track of illegal
> attempts to modify it via Unsafe / JNI / reflection? Is this really how
> finals are implemented, ie don't assume they are final?
>
> I understand when you do it the other way around - assume a unmarked field
> is final, until someone attempts to modify the field.
>
>
> Alex
>
>
> On 12/02/2013 23:09, Nathan Reynolds 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 | Architect | 602.333.9091
> Oracle PSR Engineering | 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> 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 list
> Concurrency-interest at cs.oswego.edu
> http://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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://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
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://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
>



--
Tomasz Kowalczewski

On Wed, Feb 13, 2013 at 12:28 PM, oleksandr otenko
<oleksandr.otenko at oracle.com> wrote:
> I look at it simpler.
>
> If the final-modifying code breaks the application's assumption that the
> field is final, then the final-modifying code has the problem.
>
> If the final-modifying code guarantees the application's assumption that the
> field looks final, then there is no need to distinguish the case that it may
> be modified by some external means.
>
>
> Alex
>
>
>
> On 13/02/2013 11:04, Nitsan Wakart wrote:
>
> See this :
> http://www.azulsystems.com/blog/cliff/2011-10-17-writing-to-final-fields-via-reflection
> And the follow up:
> http://www.azulsystems.com/blog/cliff/2011-10-27-final-fields-part-2
> Final fields are not treated as final because sometimes (as in: popular use
> case you can't ignore) they are not...
>
>
> ________________________________
> From: oleksandr otenko <oleksandr.otenko at oracle.com>
> To: concurrency-interest at cs.oswego.edu
> Sent: Wednesday, February 13, 2013 10:45 AM
> Subject: Re: [concurrency-interest] Stupid Question
>
> I don't get this. Why have a final, if you need to keep track of illegal
> attempts to modify it via Unsafe / JNI / reflection? Is this really how
> finals are implemented, ie don't assume they are final?
>
> I understand when you do it the other way around - assume a unmarked field
> is final, until someone attempts to modify the field.
>
>
> Alex
>
>
> On 12/02/2013 23:09, Nathan Reynolds 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 | Architect | 602.333.9091
> Oracle PSR Engineering | 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> 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 list
> Concurrency-interest at cs.oswego.edu
> http://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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://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
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://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
>



--
Tomasz Kowalczewski


More information about the Concurrency-interest mailing list