inconsistent inlining behavior with CompileOnly
tobias.hartmann at oracle.com
Wed Jun 29 13:38:44 UTC 2016
On 29.06.2016 15:32, Roland Westrelin wrote:
> Thanks for looking at this. Here is the bug:
>> 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.
More information about the hotspot-compiler-dev