RFR: 8172733: [JVMCI] add ResolvedJavaMethod.hasNeverInlineDirective

[Tom Rodriguez]

Doug Simon wrote:
>> On 23 Jan 2017, at 18:26, Vladimir Kozlov<vladimir.kozlov at oracle.com>  wrote:
>>
>> Hi, Doug
>>
>> About jvmciCompilerToVM.cpp changes. why you added CompilerOracle::should_exclude(method) check? CompilerOracle::should_not_inline() does it already except it does not check compileonly list.
>
> Ok, I don’t think we need to check the compileonly list since this is explicitly only about inlining.

That's seems inconsistent to me.  exclude and compileonly are just 
complementary ways of specifying the same thing.  Certainly in 8 C1 
respected CompilerOracle::should_exclude as meaning should_not_inline. 
Did that change in 9?  Is the mapping documented somewhere?

tom

>
>> I also thought that we should switch to using DirectiveSet::should_not_inline() as C1 and C2 does now but it is more complex change which we can do in jdk 10.
>
> Ok.
>
>> Otherwise looks good.
>
> Thanks for the review!
>
> -Doug
>> Thanks,
>> Vladimir
>>
>> On 1/22/17 12:39 PM, Doug Simon wrote:
>>> The ResolvedJavaMethod.canBeInlined method captures 2 different constraints on inlining:
>>>
>>> 1. Whether the method has an explicit directive (e.g., -XX:CompileCommand=dontinline) or a hotspot recognized annotation (e.g., @DontInline).
>>> 2. Whether hotspot has marked it not compilable for policy reasons (e.g., failed earlier compilations or has a bytecode breakpoint).
>>>
>>> Truffle partial evaluation (a JVMCI API client) doesn’t care about 2 and must ignore it for correct operation. However, it needs to know about 1. This webrev introduces a separate ResolvedJavaMethod.hasNeverInlineDirective method to support this feature.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8172733
>>> http://cr.openjdk.java.net/~dnsimon/8172733/webrev/
>>>
>>> -Doug
>>>
>