On Fri, Jan 12, 2018 at 6:36 AM Peter Levart <peter.lev...@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
