RFR: 8292194: G1 nmethod entry barrier disarm value wraps around too early

[Erik Österlund]

On Wed, 24 Aug 2022 10:04:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> The disarm value for G1 nmethod entry barriers assumes that a concurrent GC can be aborted at most once. However, it can happen many times. In order to avoid ABA issues in the nmethod entry barriers, the limit for wrapping around and reusing numbers needs to be higher. This patch changes that point to INT_MAX as there is little point in using lower values.
>
> src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 113:
> 
>> 111:   // aborted N times, that is when there could be ABA problems. If there are anything
>> 112:   // close to INT_MAX - 1 GCs starting without being able to finish, something is
>> 113:   // seriously wrong.
> 
> Unfortunately, "something is seriously wrong" is not true. I have seen benchmarks where G1 is stuck in Concurrent Undo cycles because the concurrent start gc always can always reclaim some humongous object that gets G1 below the concurrent marking threshold again. That can last for 100's of such occurrences.
> Obviously idk if before INT_MAX such concurrent undo marks there will be at least one "full" marking cycle, but there does not seem to be a guarantee.
> One solution is to force completion of a marking cycle after X (where X is a very high number) subsequent concurrent undos.

Let's say a rather rapid back to back concurrent full GC interval might be 10 ms ish. With such time intervals, it would take a bit over 16 years worth of being constantly interrupted and not finishing a single GC cycle, before any assumption would be broken. I wouldn't wish for anyone to be stuck in a single JVM for that long, hence why I think "something is seriously wrong" if that ever happened. I'm personally okay with that, and think we have bigger fish to fry. For example, the CollectedHeap::_total_collections counter is an unsigned int and there assumptions that it never wraps around. That sounds more likely to ever happen. Yet seemingly unlikely.

-------------

PR: https://git.openjdk.org/jdk/pull/9822