RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly

Nils Eliasson
Hi,

This patch fixes a problem with inconsistent inlining behavior when
using CompileCommand compileonly flag.

InlineTree::check_can_parse(ciMethod* callee) checks the
callee->can_be_compiled(), which is a wrapper of ciMethod
_is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set
1) by Compilecommands that prohibit compilation (compileonly and
exclude) at first compilation, or 2) by a compiler when a method is
failing compilation.

Because of this, a method may be inlinable before it is has been
compiled itself, but not after. This can cause unexpected problems in
test that rely on compilecommands for inlining and compilation decisions.

But... there are two sides too this:

1) It is incorrect since a method may still be inlined even though it
shouldn't be compiled.

2) It is correct, because we don't want to inline methods that failed an
earlier compilation.

In this patch I have settled with solving problem description (1) while
noting that it may cause some extra compilations that bailout because of
(2), but will still function correctly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8160548

Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/

Please review,

Nils Eliasson


Reply | Threaded
Open this post in threaded view
|

Re: RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly

Tobias Hartmann-2
Hi Nils,

this looks reasonable to me.

Best regards,
Tobias

On 10.11.2017 13:57, Nils Eliasson wrote:

> Hi,
>
> This patch fixes a problem with inconsistent inlining behavior when using CompileCommand compileonly flag.
>
> InlineTree::check_can_parse(ciMethod* callee) checks the callee->can_be_compiled(), which is a wrapper of ciMethod
> _is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set 1) by Compilecommands that prohibit compilation
> (compileonly and exclude) at first compilation, or 2) by a compiler when a method is failing compilation.
>
> Because of this, a method may be inlinable before it is has been compiled itself, but not after. This can cause
> unexpected problems in test that rely on compilecommands for inlining and compilation decisions.
>
> But... there are two sides too this:
>
> 1) It is incorrect since a method may still be inlined even though it shouldn't be compiled.
>
> 2) It is correct, because we don't want to inline methods that failed an earlier compilation.
>
> In this patch I have settled with solving problem description (1) while noting that it may cause some extra compilations
> that bailout because of (2), but will still function correctly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160548
>
> Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/
>
> Please review,
>
> Nils Eliasson
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly

Nils Eliasson
Thank you Tobias,

I might add that in the future we might want to split
ciMethod::_is_c*_compilable into separate fields for compilations
bailouts and compile command exclusions.

I'll add the test results to the bug when they are complete.

Regards,
Nils Eliasson


On 2017-11-10 14:43, Tobias Hartmann wrote:

> Hi Nils,
>
> this looks reasonable to me.
>
> Best regards,
> Tobias
>
> On 10.11.2017 13:57, Nils Eliasson wrote:
>> Hi,
>>
>> This patch fixes a problem with inconsistent inlining behavior when using CompileCommand compileonly flag.
>>
>> InlineTree::check_can_parse(ciMethod* callee) checks the callee->can_be_compiled(), which is a wrapper of ciMethod
>> _is_c1_compilable/_is_c2_compilable boolean fields. Those fields are set 1) by Compilecommands that prohibit compilation
>> (compileonly and exclude) at first compilation, or 2) by a compiler when a method is failing compilation.
>>
>> Because of this, a method may be inlinable before it is has been compiled itself, but not after. This can cause
>> unexpected problems in test that rely on compilecommands for inlining and compilation decisions.
>>
>> But... there are two sides too this:
>>
>> 1) It is incorrect since a method may still be inlined even though it shouldn't be compiled.
>>
>> 2) It is correct, because we don't want to inline methods that failed an earlier compilation.
>>
>> In this patch I have settled with solving problem description (1) while noting that it may cause some extra compilations
>> that bailout because of (2), but will still function correctly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160548
>>
>> Webrev: http://cr.openjdk.java.net/~neliasso/8160548/webrev.01/
>>
>> Please review,
>>
>> Nils Eliasson
>>
>>