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

[Peter Levart]

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
>