RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7]

[Stefan Karlsson]

On Tue, 29 Sep 2020 06:42:54 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> I think the previous assert was intentionally weaker: `is_in` checks that argument points to a committed area in the
>> heap, which can include the oops not yet fixed. It does not check if oop is valid as far as GC is concerned. So maybe
>> reverting `NativeAccess::oop_load` is enough?
>
> It was checking is_in_or_null before and after. Our is_in checks that it is in committed memory, and that the pointer
> is not stale w.r.t. color, as that is very likely to be a bug. We reluctantly made it relaxed for our safepoints that
> flip colors. I think it was once again for this very same usual suspect assert. But now that this is concurrent, its
> memory can get concurrently freed.  I think this is the 7th time I try to make this assert happy. I run into it all the
> time. IMO, the underlying assumption of the assert, is wrong. This is an iterator used by GC to fix totally invalid
> stale pointers into valid pointers. You really can't expect that they are valid before fixing them. That just happened
> to be true for other GCs. It makes little sense to me. That is why my preferred solution is to remove the assert. I
> would not miss it.  We have had similar issues with the oop_iterate framework asserting oops are valid before the
> closure is applied. At least there, it is possible to opt out...  Would anyone miss the assert?

FTR, this is the RFE to remove the oop verification from the oop_iterate framework:
https://bugs.openjdk.java.net/browse/JDK-8237363

I really would like to get rid of it, but got push back because it made GCs have to duplicate the effort to provide
verification.

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

PR: https://git.openjdk.java.net/jdk/pull/296