inconsistent inlining behavior with CompileOnly

[Tobias Hartmann]

Hi Roland,

On 29.06.2016 15:32, Roland Westrelin wrote:
> Tobias,
> 
> Thanks for looking at this. Here is the bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8160548
> 
>> 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)
>>
>> [...]
> 
> 
> Is the historical behavior (that excluding some methods from compilation
> also forbids inlining of those methods) still the expected behavior?
> 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.

I'm not sure about this but in the case you pointed out there is clearly an inconsistency. I agree that for most use cases it would be better to only exclude "root compilations" and keep the inlining behavior untouched.

Best regards,
Tobias

> 
> Roland.
>