On 04/02/18 20:01, Martin Buchholz wrote:
On Fri, Mar 30, 2018 at 6:31 PM, Martin Buchholz <marti...@google.com
<mailto:marti...@google.com>> wrote:
Thanks, John.
I need to adjust my expectations. The word "constant" means
something different to hotspot engineers.
I'm still hoping to someday simply say,
"here's a final field - just go ahead and trust that it's truly final"
In retrospect, I think this wording in the docs raised my expectations:
"""a final stable field is treated as if it is really final from both
the Java language and the HotSpot VM."""
The thing is what you expect "really final field" to be treated like by
VM. For its value to be hoisted out of loop it need not be really final
at all, just not volatile. For its value to be compiled into a constant
embedded into generated native code, it is not enough to be just really
final - it must also be in an object that is considered constant.
Regards, Peter
On Fri, Mar 30, 2018 at 4:38 PM, John Rose <john.r.r...@oracle.com
<mailto:john.r.r...@oracle.com>> wrote:
The docs for @Stable don't spell this out as clearly as one
might want, but this sentence comes closest: "More specifically,
the HotSpot VM will process non-null stable fields (final or
otherwise) in a similar manner to static final fields with
respect to
promoting the field's value to a constant."
