inconsistent inlining behavior with CompileOnly

[Vladimir Kozlov]

I thought always compileonly excludes compilation *and* inlining of 
other methods. But running with jdk6, 7 and 8 shows changed behavior:

jdk6:
   1   b   TestCompileCommand::m1 (4 bytes)
       @ 0   TestCompileCommand::m1_notinlined  inline (hot)
   2   b   TestCompileCommand::m2 (8 bytes)
       @ 4   TestCompileCommand::m2_notinlined  inline (hot)

jdk7 and jdk8:

     212    1    b        TestCompileCommand::m1 (4 bytes)
                             @ 0   TestCompileCommand::m1_notinlined (1 
bytes)   failed_initial_checks
     220    2    b        TestCompileCommand::m2 (8 bytes)
                             @ 4   TestCompileCommand::m2_notinlined (1 
bytes)   failed_initial_checks

May be something changed later in jdk 9. But I think jdk 9 should be 
consistent with previous release (jdk8).

And documentation says nothing about inlining.

http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#CBBIJCHG

Regards,
Vladimir

On 6/29/16 6:54 AM, Vladimir Ivanov wrote:
>
>> Is the historical behavior (that excluding some methods from compilation
>> also forbids inlining of those methods) still the expected behavior?
> It depends on what compile command you are talking about.
>
> For "exclude" command such behavior is expected. Disabling compilation
> of a method is used to workaround compiler bugs and it doesn't matter
> whether the problematic method is the root of a compilation or being
> inlined - compiler shouldn't try to compile the method at all.
>
> But for "compileonly" I'd prefer to see the behavior you suggest: it
> affects only root of a compilation and leave inlining decisions intact.
>
> I find it much more useful than current behavior.
>
> It seems we can do such change (I can't imagine any use cases for
> "compileonly" except testing), but it requires a CCC request.
>
> In the worst case (not allowed to change existing behavior), we can
> introduce new command.
>
> Best regards,
> Vladimir Ivanov
>
>> FWIW, I really don't like it. It usually gets in the way for typical use
>> cases: I want to only compile a set of methods because I want to focus
>> on them but I still want them to be compiled like they would be without
>> any CompileCommand arguments.
>>
>> Roland.
>>