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