Re: Idiom of Local Final Variables for Locks

This is a very good idea. I even wonder if there can be bug-free code that
modifies final fields after first use at all. That is, breaking the
assumption of immutability can be allowed to be expensive. For example I
cannot see how a loop with the buffer can remain correct, if the final
buffer were allowed to change during the loop. Or how the mutual exclusion
be guaranteed, if the lock instance were allowed to change while any thread
has access to a different instance (even if it is saved in a method local).

Alex

On Thu, 25 Jul 2019, 02:22 Gil Tene via Concurrency-interest, <
[email protected]> wrote:

>
> On Jul 24, 2019, at 5:24 PM, Remi Forax via Concurrency-interest <
> [email protected]> wrote:
>
> Furthermore, the JLS 17.5.3 said
> "In some cases, such as deserialization, the system will need to change
> the final fields of an object after construction. final fields can be
> changed via reflection and other implementation-dependent means."
>
> so if a JIT want to optimize a subsequent read of a final field, it has to
> prove that there is not access to reflection, JNI, Unsafe, MethodHandle, in
> between.
> Given that Reentrant.lock() can call park() which is a C call, i doubt
> Hotspot will be ever be able to optimize that code apart if park() is
> artificially marked has "this is a pure function".
>
>
> Actually, this is optimize-able. And doing so turns out to be a win in
> some surprisingly common code idioms
>
> We optimize instance-final fields in Zing (with Falcon) with our "Truly
> Final" speculative optimization. I.e. we speculate that instance fields
> declared final are actually and truly final, and deal with the exceptional
> cases where they are not. The JIT speculatively assumes that instance final
> fields will not be modified, and optimizes based the (registered)
> assumption (much like unguarded inlining of monomorphic non-final methods
> works). The JVM enforces the assumption by intercepting any changes to
> instance final fields by e.g. reflection, Unsafe, JNI, or MethodHandles,
> and will de-optimize assumption-dependent methods before any changes to the
> fields that they assume are final can take hold.
>
> My favorite example of this (surprisingly) taking hold comes from code
> that looks like this, and is quite common in the wild:
>
> class FastDoof {
>     private final long[] buf = new int[MAX_BUFLEN];
>     private long residual;
>     …
>
>     public long doSomethingFast(int val) {
>       for (int i = 0; i < buf.length; i++) {
>         computeResidual(buf[i], residual);
>       }
>       return residual;
>     }
>     …
> }
>
> It turns how that (without the Truly Final optimization) the following
> code is measurably faster on HotSpot:
>
>     public long doSomethingFast(int val) {
>       final localBuf = buf;
>       for (int val : buf) {
>         computeResidual(val, residual);
>       }
>       return residual;
>     }
>
> That is because the loop above is actually the semantic equivalent of this
> code:
>
>     public long doSomethingFast(int val) {
>       final localBuf = buf;
>       for (int i = 0; i < localBuf.length; i++) {
>         computeResidual(localBuf[i], residual);
>       }
>       return residual;
>     }
>
> Which allows the hoisting of the array range check out of the loop (since
> localBuf is actually known to remain final during the loop execution).
>
> With the Truly Final optimizations (which Zing does right now), all the
> loop versions above end up doing the same thing...
>
> You can see more on this in Nistan Wakart's blog entry here:
> http://psy-lob-saw.blogspot.com/2014/02/when-i-say-final-i-mean-final.html
>
> But, with all that said, I agree that the idiom itself is "much better"
> for the writing of lock code in methods, because it insolates the locking
> code's correctness from the potential of the lock field itself being
> (mistakenly declared non-final, or made practically-non-final for any
> reason...
>
>
>
> regards,
> Rémi
>
> ------------------------------
>
> *De: *"concurrency-interest" <[email protected]>
> *À: *"Dr Heinz M. Kabutz" <[email protected]>
> *Cc: *"Joe Bowbeer" <[email protected]>, "concurrency-interest" <
> [email protected]>
> *Envoyé: *Jeudi 25 Juillet 2019 01:42:46
> *Objet: *Re: [concurrency-interest] Idiom of Local Final Variables for
> Locks
>
>
>
> On Tue, Jul 23, 2019 at 8:10 AM Dr Heinz M. Kabutz via
> Concurrency-interest <[email protected]> wrote:
>
>> Thanks so much Joe.  So there was a performance gain at some point, but
>> hopefully HotSpot fixed that, I guess :-)
>>
>
> Sorry, no.
>
>
> https://openjdk.markmail.org/message/2tldq6t3ihhxskz5?q=from:rose+%40Stable+list:net%2Ejava%2Eopenjdk%2Ecore-libs-dev&page=1
>
> But even if we could totally trust hotspot, it's such a good practice (for
> correctness and performance) to copy fields into locals in concurrency
> libraries that we would probably keep on doing it.
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest