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

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 12 12:11:37 UTC 2018

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.

Regards, Peter -- Sent from my phone

More information about the core-libs-dev mailing list