RFR: 8270459: Conflict inlining decisions by C1/C2 with the same CompileCommand

Vladimir Kozlov kvn at openjdk.java.net
Wed Jul 14 16:11:10 UTC 2021


On Wed, 14 Jul 2021 12:59:53 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Conflict inlining decisions can be observed by C1/C2 with the same CompileCommand.
> And I came across this situation while I was analyzing a performance issue using the jmh, which made me quite confused.
> 
> For the example in the JBS.
> 
>      28    1 %     3       TestInline::main @ 11 (43 bytes)
>                               @ 23   TestInline::caller (4 bytes)   disallowed by CompileCommand
>      29    2       3       TestInline::main (43 bytes)
>                               @ 23   TestInline::caller (4 bytes)   disallowed by CompileCommand
>      31    3 %     4       TestInline::main @ 11 (43 bytes)
>      33    1 %     3       TestInline::main @ 11 (43 bytes)   made not entrant
>                               @ 23   TestInline::caller (4 bytes)   force inline by CompileCommand
> 
> 
> This can be easily reproduced by specifying both the `inline` and `dontinline` compile commands for a method.
> 
>    -XX:CompileCommand=inline,TestInline::caller \
>    -XX:CompileCommand=dontinline,TestInline::caller \
> 
> 
> The fix will ignore the inline/not-inline directives if both the `inline` and `dontinline` compile commands are specified for a method.
> 
> Effect of the patch:
> 
>      27    1 %     3       TestInline::main @ 11 (43 bytes)
>                               @ 23   TestInline::caller (4 bytes)   inline
>      28    2       3       TestInline::main (43 bytes)
>                               @ 23   TestInline::caller (4 bytes)   inline
>      28    3 %     4       TestInline::main @ 11 (43 bytes)
>      30    1 %     3       TestInline::main @ 11 (43 bytes)   made not entrant
>                               @ 23   TestInline::caller (4 bytes)   inline (hot)
>      31    3 %     4       TestInline::main @ 11 (43 bytes)   made not entrant
> 
> 
> Testing:
>   - tier 1~3 on Linux/x64, no regression
> 
> Thanks.
> Best regards,
> Jie

In HotSpot the last specified option overwrites all previous.
I am not sure we keep information about CompileCommand options order but we have to follow general rule.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4780


More information about the hotspot-compiler-dev mailing list