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

Vladimir Ivanov vladimir.x.ivanov at
Mon Jan 15 12:10:46 UTC 2018

>     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

More information about the core-libs-dev mailing list