> On Jan 15, 2018, at 6:51 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> > wrote: > > Jason, > > I wouldn't consider @Stable as a scalpel :-) > > It's heavily locked down for a reason: it wasn't designed for eventual > standardization, but as (1) an experiment in _multiple_ directions; and (2) > solution for immediate problems in java.lang.invoke. > > @Stable mixes (incomplete implementations of) 2 independent features (lazy > initialization of finals + constant arrays), while trusting instance finals > is just a consequence of locking it down to privileged code (JIT-compilers > already trust final instance fields in different core packages). > > Current implementation doesn't enforce at runtime the contract and allows > multiple writes to @Stable field. It is useful in rare cases, but overall > significantly complicates proper usage of @Stable. > > All those factors make @Stable unfit for public exposure in it’s current form. > > Both referenced features are independently explored (as lazy finals and > frozen arrays). > > Also, @Stable is not a substitute for final fields: default value is treated > specially (not optimized), while "final" covers the whole range of values of > a type. > > For optimizing final fields there are much more promising approaches: > > (1) optimistic optimizations in JITs: treat finals as constants and track > updates invalidating code which relies on that (there were some experiments, > e.g. [1]); > > (2) forbid final field updates at runtime after initialization is over and > freely optimize them in JITs. > > Both approaches still have some roadblocks on their way (deserialization > relies on modifying final fields, hard to track final field values of > individual objects in JVM, etc), but the platform steadily moves in the > direction of treating final fields as truly final by default.
Thanks for the explanation Vladimir, I can certainly understand optimistic optimization being the end goal, but, correct me if I am wrong, it seems an improvement in the distant future. I can see the issue is scheduled for 11, but I imagine that is more of a placeholder. Has a narrow variant of (2) in the same vein as @Stable been considered, as it seems to overcome the roadblocks mentioned? An annotation placed on a final field (something like @Constant, @StrictFinal, @ImmutableAfterPublish, whatever) could indicate opting in to the contract of this field as a truly final field, freeing the JVM to optimize and validate as desired (e.g. special case serialization, preventing setAcessible/JNI set field/VarHandle/etc), and without introducing compatibility issues. I realize validating access via Unsafe is non-trivial, but I argue there is limited value in doing so, since the effects are not worse than other actions one might take with Unsafe. Further, I argue any validation at all is going above and beyond, as “undefined” is a perfectly reasonable result for contract violations. -Jason
