[concurrency-interest] Stupid Question

oleksandr otenko oleksandr.otenko at oracle.com
Wed Feb 13 06:28:16 EST 2013


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 
>> <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>  <mailto:dl at cs.oswego.edu>  wrote:
>>>> On 02/12/13 15:41,javamann at cox.net  <mailto: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  <mailto:Concurrency-interest at cs.oswego.edu>
>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu 
> <mailto: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/c29dcfc7/attachment.html>


More information about the Concurrency-interest mailing list