On Tue, 29 Sep 2020 07:24:16 GMT, Stefan Karlsson <stef...@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
