RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method

[Vladimir Kozlov]

I agree with separate RFE.

Thanks,
Vladimir

On 5/6/16 3:17 AM, Doug Simon wrote:
>
>> On 05 May 2016, at 23:56, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> On 5/5/16 2:14 PM, Doug Simon wrote:
>>>
>>>> On 05 May 2016, at 20:06, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain.
>>>
>>> Ok, I added the missing #if INCLUDE_JVMCI guards. Are there regular test builds with INCLUDE_JVMCI=0 that would have caught this?
>>
>> Try to use JPRT test run (-stree .). It will build on all platforms and some have INCLUDE_JVMCI = 0.
>>
>>>
>>>> In thread.hpp is there a reason to use several bool fields instead of one field for flags?
>>>
>>> Probably didn’t seem worth it when there were only 2 bool fields. Now that there will be three, should I convert to using a flags field?
>>
>> Yes please use flags field (after int field to get more compact data).
>
> I've filed this as a separate bug (https://bugs.openjdk.java.net/browse/JDK-8156206) as it’s a somewhat larger change given that at least one of these fields is accessed from Java code and so we need to now expose both the flags field and flags constant via HotSpotVMConfig and change the logic to do bit twiddling instead of a simple byte filled update.
>
> For 8152311, I’ve made the bool fields adjacent now.
>
> -Doug
>
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Thanks for the review.
>>>
>>> -Doug
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/5/16 5:39 AM, Doug Simon wrote:
>>>>> Please read the bug for a full description of this proposed change.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8152311
>>>>> http://cr.openjdk.java.net/~dnsimon/8152311/
>>>>>
>>>>> -Doug
>>>>>
>>>
>