Can @Stable (or something similar) be made accessible?
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 , 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?
>> Regards, Peter
> Sent from my phone
More information about the core-libs-dev