No, it doesn't work that way. @Stable enables JIT to constant fold
loads from fields/arrays (holding non-default values) whenever
possible. After that JIT has a constant value at its hands. All
other optimizations follows from that: range check before array
store can be elided since array instance is known and its length is
known as well, type check can be elided since constant type is
known. But the value won't be reloaded from memory, all
optimizations happen on a constant which was loaded from memory once
during compilation.
So, the worst case scenario is: a value written into @Stable
field/array is never visible in some code no matter what you do. It
can lead to nasty bugs when different parts of program don't agree
on observed value. It can happen when user doesn't obey @Stable
contract and performs multiple writes into a @Stable field/array.
Current implementation in HotSpot doesn't forbid that.
Thanks for clarifying Vladimir - that makes sense. So back to the
integrity of the VM question - what can be compromised then? I suppose
if one was to use Unsafe access in combination with relying on a @Stable
field to feed it info (e.g. index into some memory accessed via Unsafe),
then things can go south. But Unsafe is already, well, unsafe. What
extra VM integrity issues would a misbehaving @Stable cause that Andrew
was alluding to?
I don't know what exactly Andrew had in mind.
Though misuse of @Stable can't be a direct cause of JVM crashes, it can
lead to serious bugs in user code which manifest themselves as
JIT-compiler bugs. And miscompiled code silently corrupting user data is
usually considered much more serious issue than a JVM crash.
Best regards,
Vladimir Ivanov
