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

[Vitaly Davidovich]

>
> In non-"this" case, you may not be able to prove the A*FU receiver is
> non-null.


Yes (particularly annoying since final instance fields aren't treated as
constants :)).

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.


In this particular case, A*FU is doing obj.getClass() == tclass as a
cheaper check than what fullCheck() does, which is tclass.isInstance(obj).
However, theoretically speaking, if A*FU op is inlined into an instance
method where `this` is passed, it should be able to determine at JIT time
whether `this` is tclass or subtype of it.  Then that whole type check
could be removed.

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


Yes, sorry -- I blame Remi for digressing :).


On Mon, Oct 26, 2015 at 7:41 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> 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.
>
> Thanks,
> -Aleksey
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151026/8cdf7321/attachment.html>