[concurrency-interest] Stupid Question

Nitsan Wakart nitsanw at yahoo.com
Wed Feb 13 06:04:48 EST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/841127a4/attachment-0001.html>


More information about the Concurrency-interest mailing list