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" <sh...@redhat.com> > À: "Jason Greene" <jason.gre...@redhat.com>, "core-libs-dev" > <core-libs-dev@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
