[concurrency-interest] Stupid Question

Markus Krainz ldm at gmx.at
Wed Feb 13 07:10:04 EST 2013


Hi,

I have read that blog post some time ago. It uses the SwitchPoint class 
to optimize the access.
I am wondering, could this be more efficient than the double-checked 
locking idiom used e.g. for lazy initialization?

Regards,
Markus Krainz

Am 13.02.2013 12:41, schrieb Tomasz Kowalczewski:
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list