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

[Zhengyu Gu]

Thanks, Erik.

-Zhengyu

On 7/18/19 10:17 AM, Erik Osterlund wrote:
> Hi Zhengyu,
> 
> Looks good.
> 
> Thanks,
> /Erik
> 
>> On 18 Jul 2019, at 16:12, Zhengyu Gu <zgu at redhat.com> wrote:
>>
>> 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
>