RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class()
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Aug 1 15:03:00 UTC 2017
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.
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
>>>
>>
More information about the hotspot-dev
mailing list