RFR: Some patches for sherman
peter.levart at gmail.com
Mon Apr 2 22:29:50 UTC 2018
On 04/02/18 20:01, Martin Buchholz wrote:
> On Fri, Mar 30, 2018 at 6:31 PM, Martin Buchholz <martinrb at google.com
> <mailto:martinrb at 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.
> On Fri, Mar 30, 2018 at 4:38 PM, John Rose <john.r.rose at oracle.com
> <mailto:john.r.rose at 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."
More information about the core-libs-dev