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

Laurent Bourgès bourges.laurent at gmail.com
Fri Jan 12 09:06:41 UTC 2018

Hi,

I am the author of the Marlin renderer, integrated in both java.desktop & javafx.graphics modules.

I wonder if such core annotations @Stable @ForceInline ... could be allowed to such openjdk modules in order to improve performance.

Marlin already uses jdk.internal.Unsafe but @Stable looks promising as Marlin uses (and recycles) lots of int/double arrays.

I already made my fields (& constants) final but it is not enough to let hotspot trust totally my code, isn't it ?

I think these annotations are confined to java.lang for now. I will check thatasap.

Cheers, Laurent

Le 12 janv. 2018 9:50 AM, "Andrew Haley" <aph at redhat.com> a écrit :

On 12/01/18 04:33, Jason Greene wrote:

> The internal @Stable facility provides the desired semantics and > precision, but it is heavily locked down, with privileged code > checks and export restrictions. Could this be made more accessible > (or perhaps a variant restricted to just final fields)? Informing > the compiler that a final field is a true lazy initialized constant, > with no store-to-final seems a pretty useful construct in general. I > can understand that the long term desire is that this shouldn’t be > necessary, and should be inferred [3], but at that point the > annotation is still useful as documentation and legacy > compatibility. If nothing else could it be allowed in non-privileged > code via some flag? I don't know of any way to do that without compromising the integrity of the JVM. All that anybody would have to do to break the VM is to define a field as @Stable and then change the field. I suppose you could say that Unsafe is just as bad and people still are allowed to use it, but there's understandable reluctance any further to transform a safe runtime into an unsafe one. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the core-libs-dev mailing list