[14] RFR(S) 8236050: Some compiler tests fail when executed with custom TieredLevel

[Claes Redestad]

Thanks, looks good to me!

/Claes

On 2020-01-04 01:28, Igor Veresov wrote:
> Ok, we can add some verification: 
> http://cr.openjdk.java.net/~iveresov/8236050/webrev.01/
> 
> igor
> 
> 
> 
>> On Jan 3, 2020, at 7:44 AM, Claes Redestad <claes.redestad at oracle.com 
>> <mailto:claes.redestad at oracle.com>> wrote:
>>
>> Right, it seemed to be the case, but I couldn't conclude it by reading
>> the surrounding/calling code. That's why I commented that the logic is a
>> bit hard to follow. :-)
>>
>> I think an assert that the level argument is always valid would be a
>> sufficient guide here.
>>
>> /Claes
>>
>> On 2020-01-03 16:16, Igor Veresov wrote:
>>> That’s not a problem, the level argument is always valid. The case 
>>> this change is fixing is the situation when the level needs to be 
>>> changed due to TieredStopAtLevel (i.e. when level > TieredStopAtLevel).
>>> igor
>>>> On Jan 3, 2020, at 2:53 AM, Claes Redestad 
>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> logic in limit_level is a bit hard to follow. In case TieredStopAtLevel
>>>> is 4, level is 2 or 3 and compilation mode is high-only or high-only-
>>>> quick-internal it seems it'll return level, which is an invalid level
>>>> for the compilation mode..?
>>>>
>>>> /Claes
>>>>
>>>> On 2020-01-02 16:00, Igor Veresov wrote:
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8236050/webrev.00 
>>>>> <http://cr.openjdk.java.net/~iveresov/8236050/webrev.00>
>>>>> This change makes the TieredStopAtLevel processing aware of various 
>>>>> compilation modes.
>>>>> Thanks!
>>>>> igor
>