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

[Erik Österlund]

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