On Tue, 29 Sep 2020 06:42:54 GMT, Erik Österlund <eosterl...@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
