RFR (S) 8141044: C1 should fold (this == null) to false
Aleksey Shipilev
aleksey.shipilev at oracle.com
Mon Nov 2 21:52:57 UTC 2015
Hi Kris,
Thank for the review!
On 11/03/2015 12:27 AM, Krystal Mok wrote:
> Let's imagine this kind of example (deriving from your earlier example):
>
> void foo(Bar obj) {
> obj.bar();
> // or if Bar obj came here from a return value of another method
> }
>
> void bar() {
> quux(this);
> }
>
> void quux(Object o) {
> if (o == null) throw new Exception();
> }
>
> If the call path foo() -> bar() -> quux() is fully inlined in C1, then
> for the bar() method the 'this' value wouldn't have been a Local[0],
> thus it'd miss the optimization you implemented.
Ah, yes... That is probably a deal-breaker for the A*FU cases I am
trying to optimize. The A*FU.get(this) would certainly be inlined, and
this-ness would be lost.
> But if whenever a value is used as a receiver on some path, after the
> NullCheck, tag the type of the value to be _is_receiver = true, then the
> example above would be optimized as well.
>
> This alternative is a bit more involved than your original change, since
> you can't globally change the type (or any attributes on the type) of a
> value if the type only applies to some certain path but not all paths.
>
> For example,
>
> void foo(Bar o, boolean cond) {
> if (cond) {
> o.bar(); // o used as a receiver on this path
> } else {
> // o not used as a receiver on this path
> }
> // Should the type of o be tagged as _is_receiver here? No.
> }
>
> So it's better to piggyback on the C1 Optimizer passes to implement this
> alternative than in the Canonicalizer.
Yeah, I wonder if NullCheckEliminator can analyze the flow like that
already? Or, have we lost the "local/receiver" info after inlining? Need
to see the LIR after inlining there.
Thanks,
-Aleksey
-------------- 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/20151103/f2cf18cf/signature-0001.asc>
More information about the hotspot-compiler-dev
mailing list