On Mon, 28 Sep 2020 16:41:28 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
>> src/hotspot/share/compiler/oopMap.cpp line 319:
>>
>>> 317: #ifdef ASSERT
>>> 318: if ((((uintptr_t)loc & (sizeof(oop)-1)) != 0) ||
>>> 319:
>>> !Universe::heap()->is_in_or_null((oop)NativeAccess<AS_NO_KEEPALIVE>::oop_load(&val)))
>>> {
>>
>> This NativeAccess call causes the troubles with Shenandoah GC. It triggers
>> evacuation of the object referenced by the
>> stack location during a safepoint, which we'd rather avoid. Why is it needed?
>
> We call frame::oops_do from the GC to make bad oops good. But the oops_do
> logic assers the oop is good *before* the
> closure is applied. Every time I do something, I run i to issues with this
> assert. It seems like an invalid assumption
> to me, that oops are meant to always be good, even before they are fixed. I
> vote for removing this assert. It has
> caused a lot of pain. Any takers?
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?
-------------
PR: https://git.openjdk.java.net/jdk/pull/296
