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

Peter Levart peter.levart at gmail.com
Fri Jan 12 12:37:30 UTC 2018

On 01/12/2018 01:11 PM, Vitaly Davidovich wrote:

On Fri, Jan 12, 2018 at 6:36 AM Peter Levart <peter.levart at gmail.com> wrote:

Hi Andrew,

On 01/12/2018 09:47 AM, Andrew Haley wrote: 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. Would you be so kind to explain how this breakage occurs? I can understand that improper use of @Stable annotation may break the intended semantics of a program, but to break the integrity of VM? I'm trying to imagine the scenario, but can't. One example might be a @Stable array field used with a constant index to write a value into it. If the JIT trusts the field to be final it could elide a range check when storing into the slot. If the field is actually modified to be a smaller length array, you’d end up with a write to an out of bounds memory area. I suppose something similar can be done with a non-array field - make the field type Object, store a Foo initially. The JIT can assume the type is always Foo and generate read/writes using its layout. Then change the field to another type.

So you are saying that JIT might optimize some aspects of code assuming the "constantness" of the value of the field (for example inline code for a particular type of object or skip index range check), but not optimize other aspects - for example still read the value of the field from the field's primary location in containing object to obtain 'this' pointer or index value. Is this really they way JIT does compilation/optimization? I would assume that if JIT optimizes code assuming some value is constant, it also uses this same constant value in the optimized code and not emit code that actually reads the value from the primary field location or assume that that value already resides in some register which was established in non-optimized part of code. I'm probably wrong in assuming that.

So one that uses @Stable annotation on fields in JDK internals must be very careful not to break the rules which are very subtle or he may create situations that compromise stability of VM? There are places in JDK using @Stable annotations where such marked fields can be written to more than once with different values (racy caching). Are you saying that all those values that are written to a @Stable field must be equivalent not only in terms of Java logic but in case they are reference values, they must also point to the object of the same runtime class or else the stability of VM may be compromised?

Thanks,

Peter

Regards, Peter -- Sent from my phone

More information about the core-libs-dev mailing list