[concurrency-interest] Stupid Question

Vitaly Davidovich vitalyd at gmail.com
Tue Feb 12 16:46:32 EST 2013


So Cliff Click had a few blogs on this.  Apparently, some popular
frameworks muck around with final fields (I.e. change them via
reflection).  One of his arguments was that enregistering final fields
isn't all that profitable since the 2nd load will most likely hit L1 and be
only marginally slower.  I can see that point, but I'd say it's unfortunate
that JIT writers can't liberally enregister final fields due to someone
doing bizarre things with them.

Sent from my phone
On Feb 12, 2013 4:40 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> On 02/12/2013 10:21 PM, Doug Lea 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.
>>
>
> It's not exactly that the VM is not smart enough, it's that the VM may not
> see enough.
> In the example, the VM has to be able to inline the whole graph of method
> behind the call lock.lock() to be sure that no method that is part of this
> graph contains code that may change the value of the field lock*. If the VM
> can prove that, the field doesn't need to be re-loaded when calling
> lock.unlock().
>
>
>> -Doug
>>
>
> Rémi
> * and yes, final field can be changed.
>
>
>>
>>
>>  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<Concurrency-interest at cs.oswego.edu>
>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>>
>>>
>> ______________________________**_________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>
>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130212/92b4881d/attachment.html>


More information about the Concurrency-interest mailing list