RFR (S) 8141044: C1 should fold (this == null) to false

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 2 11:41:49 UTC 2015


Got it, thanks.  From the code it looked like only slot 0 was treated as
receiver, and I wasn't sure how slot 1 (in your example) propagated.

sent from my phone
On Nov 2, 2015 6:14 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> On 11/01/2015 10:25 PM, Vitaly Davidovich wrote:
> > Doesn't your patch only work for the implicit 'this' argument to
> > instance methods? It seems like only local at slot 0 is marked as
> > receiver - what if 'this' is passed as one of the remaining args?
>
> See e.g. the targeted benchmark from
>   https://bugs.openjdk.java.net/browse/JDK-8141044
>
>
>     @Benchmark
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     public void test() {
>         m(this);
>     }
>
>     private void m(Object o) {
>         if (o == null) {
>             throw new IllegalArgumentException();
>         }
>     }
>
> ...where "this" from the caller is passed through the slot 1 (slot 0 is
> taken by the receiver for m()):
>
>   private void m(java.lang.Object);
>      0: aload_1
>      1: ifnonnull     12
>      4: new           #3   // class java/lang/IAE
>      7: dup
>      8: invokespecial #4   // Method java/lang/IAE."<init>":()V
>      11: athrow
>      12: return
>
>
> If you are compiling m() alone, there is no chance in statically
> figuring out slot 1 contains "this". C2 is also unable to figure this
> out, if you, say, break the inlining for m(). So yes, you might say it
> only works for the implicit "this", but...
>
> If you inline m() into test(), then "this"-ness would propagate from the
> test() to the m(). This happens even with the trivial dataflow that C1
> apparently does (by figuring out the "defining" instruction), and that
> will naturally conclude "o" is actually "this".
>
> This is why the benchmark improves in C1 with a suggested patch.
>
> Thanks,
> -Aleksey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151102/42f16764/attachment.html>


More information about the hotspot-compiler-dev mailing list