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

[Erik Osterlund]

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