RFR(XS): 8160548: Inconsistent inlining behavior with CompileOnly
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.
On 2017-11-10 14:43, Tobias Hartmann wrote:
> Hi Nils,
> this looks reasonable to me.
> Best regards,
> On 10.11.2017 13:57, Nils Eliasson wrote:
>> 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