RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Oct 26 23:41:50 UTC 2015

On 10/27/2015 02:18 AM, Vitaly Davidovich wrote:
>     There are, in fact, subclasses of AFUBench generated by JMH itself, so
>     you cannot elide the typecheck. If you would do the A*FU ops against
>     some pristine "holder" class, then a typecheck will be elided, and only
>     a nullcheck will be present.
> If the A*FU op is inlined into caller, I'd hope the null check is
> removed as well.  Likewise, if it's inlined into caller, `this` class is
> known at JIT time of the caller, so should be able to fold
> obj.getClass() == tclass to true or false?

In non-"this" case, you may not be able to prove the A*FU receiver is
non-null. In "this" case, you may not be able to prove the type is
unique, as that simple benchmark demonstrated. Although, I think in most
practical cases you are able to do either.

But, I think this has little to do with the current topic: trusting
final fields in A*FU enables optimizations.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151027/96d83863/signature.asc>

More information about the hotspot-compiler-dev mailing list