RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class()

[coleen.phillimore at oracle.com]

On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote:
>
>
> On 8/1/17 10:45 AM, Zhengyu Gu wrote:
>> How about setup a marker before entering the loop, ensure the loop 
>> won't come back to initial entry?
>
> It's ok for the loop to get back to the initial entry though.... if 
> there are less classes than the count in compilationPolicy.

Sorry, I'm wrong about this.  Maybe this makes sense too, but not as an 
assert but as a terminating condition.

Coleen

>
> Coleen
>>
>> #ifdef ASSERT
>>   Klass* starting_class_entry = _current_class_entry;
>> #endif
>>
>>   for (int i = 0; i < max_classes; ) {
>>
>>   ....
>>
>>      ASSERT(_current_class_entry != starting_class_entry, ....)
>>    }
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote:
>>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote:
>>>>> Summary: Counting number of instanceKlass code didn't work.
>>>>>
>>>>> A late code review change caused this regression.   Tested with
>>>>> internal NSK mlvm tests with
>>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one
>>>>> where I reproduced the failure
>>>>> overnight.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev
>>>> Hm, so now that the loop variable is _conditionally_ incremented, what
>>>> guarantees the loop termination?
>>>
>>> The fact that number_of_classes can't be zero so something has to be
>>> returned?
>>>
>>> I had trouble coming up with something better.  If you have a good 
>>> idea,
>>> I'll change it.
>>>
>>> thanks!
>>> Coleen
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>
>