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

[Zhengyu Gu]

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