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

Remi Forax forax at
Fri Jan 12 17:51:12 UTC 2018

Or you can use method handles ...

I've not tested but this should work:

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.



----- Mail original -----
> De: "Aleksey Shipilev" <shade at>
> À: "Jason Greene" <jason.greene at>, "core-libs-dev" <core-libs-dev at>
> 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

More information about the core-libs-dev mailing list