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