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

Nils Eliasson nils.eliasson at oracle.com
Fri Nov 10 14:20:45 UTC 2017


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
>>
>>



More information about the hotspot-compiler-dev mailing list