RFR(S) 8227755: Need more than 2 distinct CodeCache unloading cycles

[Roman Kennke]

Looks good to me. Thanks!

Roman


> Hi Erik,
> 
> Thanks for the explanation!
> 
> I were not sure about zero value, but all tests seem happy.
> 
> Update webrev:
> http://cr.openjdk.java.net/~zgu/JDK-8227755/webrev.01/index.html
> 
> Submit tests still fine.
> 
> Thanks again.
> 
> -Zhengyu
> 
> On 7/17/19 6:53 AM, Erik Österlund wrote:
>> Hi Zhengyu,
>>
>> Having 3 distinct states seems fine. But this patch has 4 states {0,
>> 1, 2, 3}, including the illegal state 0, which is a bug. Here is why:
>>
>> The code cache cycle should never be zero, because that is the cycle
>> that newly created nmethods get assigned, forcing evaluation of oops
>> at the next call to is_unloading().
>>
>> Imagine the following series of events:
>> 1) Nmethod A is created with state 0 (cycle == 0, is_unloading == false)
>> 2) A GC happens, bumping the current unloading cycle from 3 to 0,
>> nmethod A now has dead oops in it and needs to be unloaded
>> 3) ...but callers to A->is_unloading() will get false, even though
>> it's totally toast.
>> 4) Nmethod A sticks around and callers blow up.
>>
>> So yeah, gotta make sure you don't set the current cycle to zero.
>>
>> Thanks,
>> /Erik
>>
>> On 2019-07-17 02:08, Zhengyu Gu wrote:
>>> Shenandoah may run out of memory during concurrent nmethod evacuation
>>> and upgrade to full GC. Therefore, it needs at least 3 distinct
>>> CodeCache unloading cycle numbers.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227755
>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8227755/webrev.00/
>>>
>>> Test:
>>>    hotspot_gc (fastdebug and release) on Linux x86_64
>>>    Submit tests.
>>>
>>> Thanks,
>>>
>>> -Zhengyu