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

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