[XXS] C1 misses to dump a reason when it inlines successfully
Doerr, Martin
martin.doerr at sap.com
Fri Nov 29 08:51:58 UTC 2019
Hi,
looks good to me. Thanks for cleaning it up.
Best regards,
Martin
From: Liu Xin <navy.xliu at gmail.com>
Sent: Freitag, 29. November 2019 08:17
To: Doerr, Martin <martin.doerr at sap.com>
Cc: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: [XXS] C1 misses to dump a reason when it inlines successfully
Hi, Tobias & Martin,
The original message even didn't say inline succeed or not. When I see those, I have to dig into the source code. I spent even more time because I didn't realize that those messages are from C1. That's my standpoint and motivation as a new hotspot developer.
What C2 inliner emits "inline (hot)" is not very informative neither, but at least developers know that this callee is inlined. I gave up "by the rules of C1". I think "inline" is fine. developers can also tell difference from C2's output.
I agree with you about the default parameter. Failed attempts should always have a reason. Developers can inspect them and make adjustment.
Here is a new revision. Could you take a look?
https://cr.openjdk.java.net/~xliu/8234541/01/webrev/
sample output is like this.
@ 1 java.lang.String::isLatin1 (19 bytes) inline
@ 12 java.lang.StringLatin1::charAt (28 bytes) inline
@ 15 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
@ 21 java/lang/StringUTF16::charAt (not loaded) not inlineable
@ 15 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
@ 3 java.util.stream.ReduceOps::makeInt (18 bytes) inline
@ 1 java.util.Objects::requireNonNull (14 bytes) inline
@ 8 java.lang.NullPointerException::<init> (5 bytes) don't inline Throwable constructors
@ 14 java.util.stream.ReduceOps$6::<init> (16 bytes) inline
@ 12 java.util.stream.ReduceOps$ReduceOp::<init> (10 bytes) inline
@ 1 java.lang.Object::<init> (1 bytes) inline
@ 6 java.util.stream.AbstractPipeline::evaluate (94 bytes) callee is too large
thanks,
--lx
On Thu, Nov 28, 2019 at 6:53 AM Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,
I agree with Tobias. " by the rules of C1" doesn't add any useful information IMHO.
But I'd be fine with just adding "inline" to avoid the confusion.
> Anyway, with your change, all callers now pass a msg argument and
> therefore the null handling logic
> should be removed (replaced by an assert). Also, the default value for the
> argument can be removed.
+1
Best regards,
Martin
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net<mailto:bounces at openjdk.java.net>> On Behalf Of Tobias Hartmann
> Sent: Donnerstag, 28. November 2019 15:04
> To: Liu Xin <navy.xliu at gmail.com<mailto:navy.xliu at gmail.com>>; hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: [XXS] C1 misses to dump a reason when it inlines successfully
>
> Hi,
>
> I'm still not convinced that this message adds any useful information but let's
> see what other
> reviewers think.
>
> Anyway, with your change, all callers now pass a msg argument and
> therefore the null handling logic
> should be removed (replaced by an assert). Also, the default value for the
> argument can be removed.
>
> Best regards,
> Tobias
>
> On 22.11.19 19:09, Liu Xin wrote:
> > hi, Reviewers,
> >
> > Could you review this extremely small change?
> > Bugs: https://bugs.openjdk.java.net/browse/JDK-8234541
> > Webrev: https://cr.openjdk.java.net/~xliu/8234541/00/webrev/
> >
> > When I analyzed PrintInlining, I was confused by the inline message
> without
> > any detail. It's not easy for developer to tell if this method is inlined
> > or not. This patch add a comment "inline by the rules of C1".
> >
> > I would like to add an explicit reason, but there's no decisive reason in
> > GraphBuilder::try_inline_full. It just passes all restrict rules. Any other
> > suggestion would be appreciated.
> >
> > Thanks,
> > --lx
> >
More information about the hotspot-compiler-dev
mailing list