[concurrency-interest] Stupid Question

oleksandr otenko oleksandr.otenko at oracle.com
Wed Feb 13 05:45:32 EST 2013


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>  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/eb2af89e/attachment.html>


More information about the Concurrency-interest mailing list