inconsistent inlining behavior with CompileOnly

[Tobias Hartmann]

Hi Roland,

On 29.06.2016 14:50, Roland Westrelin wrote:
> Hi Tobias,
> 
>> the only issue with CompileOnly I'm aware of is:
>> https://bugs.openjdk.java.net/browse/JDK-8071652
>>
>> Maybe Nils knows more but he's currently on vacation.
>>
>> Have you checked this with -XX:CompileCommand=compileonly ?
> 
> Same behavior with CompileCommand=compileonly
> I suspect the problem is that if a compilation of the inlined method as
> a root of the compilation is attempted before some method tries to
> inline it, the method is marked as not compilable and then later on,
> inlining fails.

Okay, so your saying that TestCompileCommand::m2_notinlined is inlined because it was not compiled as root method before and is therefore not set to not compilable (yet).

Looking at the code, we only check CompileBroker::compilation_is_prohibited() in CompileBroker::compile_method() but not when inlining a method.

I just executed a small test:
java -XX:CompileOnly=java.lang.Thread::exit -XX:+PrintInlining -XX:+PrintCompilation -Xcomp -XX:MaxInlineSize=1000 -XX:CompileCommand=quiet -version

This inlines a lot although only Thread::exit should be compiled:
   3046   24    b  3       java.lang.Thread::exit (51 bytes)
               !m             @ 12   java.lang.ThreadGroup::threadTerminated (63 bytes)
               !m               @ 6   java.lang.ThreadGroup::remove (94 bytes)
                                  @ 59   java.lang.System::arraycopy (0 bytes)   intrinsic
                                @ 17   java.lang.Object::notifyAll (0 bytes)   native method
               !m               @ 49   java.lang.ThreadGroup::destroy (138 bytes)
                                  @ 5   java.lang.ThreadGroup::checkAccess (14 bytes)
                                    @ 0   java.lang.System::getSecurityManager (4 bytes)   not compilable (disabled)

[...]

"java.lang.System::getSecurityManager" is compiled before and set to not compilable whereas "java.lang.ThreadGroup::checkAccess" is not compiled before and inlined.

So it looks like your theory is correct. Could you file a bug?

Best regards,
Tobias

> 
> Roland.
> 
>>
>> Best regards,
>> Tobias
>>
>> On 29.06.2016 14:19, Roland Westrelin wrote:
>>>
>>> With the testcase below, executed with latest hs-comp with:
>>>
>>> java -XX:CompileOnly=TestCompileCommand::m1 -XX:CompileOnly=TestCompileCommand::m2 -XX:CompileCommand=quiet -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation TestCompileCommand
>>>
>>> I get the following output:
>>>
>>>     170    1    b        TestCompileCommand::m1 (4 bytes)
>>>                             @ 0   TestCompileCommand::m1_notinlined (1 bytes)   not compilable (disabled)
>>>     170    2    b        TestCompileCommand::m2 (8 bytes)
>>>                             @ 4   TestCompileCommand::m2_notinlined (1 bytes)   inline (hot)
>>>
>>> Either both m1_notinlined & m2_notinlined should be inlined or neither
>>> should be. Is this a known issue?
>>>
>>> Roland.
>>>
>>>
>>> public class TestCompileCommand {
>>>
>>>     static void m1_notinlined() {
>>>     }
>>>
>>>     static void m1() {
>>>         m1_notinlined();
>>>     }
>>>
>>>     static void m2_notinlined() {
>>>     }
>>>
>>>     static void m2(boolean flag) {
>>>         if (flag) {
>>>             m2_notinlined();
>>>         }
>>>     }
>>>
>>>     static public void main(String[] args) {
>>>         for (int i = 0; i < 20000; i++) {
>>>             m1_notinlined();
>>>             m1_notinlined();
>>>             m1();
>>>             m2((i%2) == 0);
>>>         }
>>>     }
>>> }
>>>