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

[Per Liden]

On Tue, 29 Sep 2020 07:24:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> 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.

I've also has problems with this assert in the past, and I think that the underlying assumption of the assert is wrong.
I would not miss it.

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

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