Can @Stable (or something similar) be made accessible?

[Remi Forax]

Or you can use method handles ...

I've not tested but this should work:
https://gist.github.com/forax/e49d63d50e5973f602f720ba3b6ea1b8

I have implemented two semantics, either do a call to get field value the first time (FIRST_WIN) and then for the subsequent calls always return this value as a constant or put a guard (if) that checks that the reference never change so instead of getting the field value, i always return the same constant (STABLE).

You may think that it doesn't work because the method handle is a captured value of a lambda that is stored in a field of the lambda proxy but the VM has a special case for that (fields of VM anonynous classes (as the lambda proxies) are always trusted, see [1]). So it's safe, from the perf POV to use lambdas has a mechanism to hidden the method handle incantations.

cheers,
Rémi

[1] https://shipilev.net/jvm-anatomy-park/17-trust-nonstatic-final-fields/

----- Mail original -----
> De: "Aleksey Shipilev" <shade at redhat.com>
> À: "Jason Greene" <jason.greene at redhat.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 12 Janvier 2018 11:37:37
> Objet: Re: Can @Stable (or something similar) be made accessible?

> On 01/12/2018 05:33 AM, Jason Greene wrote:
>> MethodHandle.invokeExact() can match the performance of direct invocation, but
>> it requires
>> constant folding to do so. Otherwise results are similar to Java reflection(e.g
>> [1]).
>> 
>> While TrustFinalNonStaticFields can be used, it’s a sledgehammer where a scalpel
>> is really be
>> more appropriate.
> 
> So, the easier way out would be enable TrustFinalNonStaticFields to be used with
> finer-grained
> control, that JEP 165 (Compiler Control) provides. Then you can tell which
> user-side
> classes/packages are safe for trusting, and which are not. IIRC, the reason why
> TrustFinalNonStaticFields is not on by default is because we cannot rely that
> everyone is not
> writing to final fields and expecting update to be visible.
> 
> ...which makes this one partially go away:
> 
>> It seems odd that the much more aggressive facility (TrustFinalNonStaticFields)
>> is simpler to
>> use than a more targeted one.
> Thanks,
> -Aleksey