RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed
Bengt Rutisson
bengt.rutisson at oracle.com
Fri Mar 13 08:45:03 UTC 2015
On 2015-03-12 22:16, Kim Barrett wrote:
> On Mar 12, 2015, at 6:19 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>> A more stable approach that would actually allow us to enforce the SATB invariant might be to:
> The SATB invariant doesn't matter at present, because we aren't
> eagerly reclaiming humongous objects that contain references
Maybe I am splitting hairs here, but I do think the SATB invariant
matter. The reason we have the bug you are trying to fix is due to the
fact that early reclaim breaks the SATB invariant.
You didn't really comment on my suggested way of addressing the problem.
Do you think it would be doable? I think it would be more stable.
Another alternative would be to let initial marking note all humongous
objects that were live after initial mark. Then we can just make sure
that early reclaim does not reclaim any of those humongous objects while
marking is active. That should be a pretty simple fix that can be
backported if necessary.
Thanks,
Bengt
> (up to
> needing to fix https://bugs.openjdk.java.net/browse/JDK-8072598). It
> will matter if/when we attempt to address JDK-8073288 or JDK-8048180.
> But as is said in JDK-8048180
>
> However, the early reclaim mechanism should be seen as something
> for picking low-hanging fruits, not a replacement for the global
> marking, ...
>
> I'm sure there are counter examples (no matter how crazy some behavior
> seems, some application somwhere will exhibit it), but I suspect the
> vast majority of humongous objects that can even potentially be
> reclaimed via this mechanism are basically byte blobs of one kind or
> another. If that's true then having eager reclaimation only apply to
> such byte blobs (e.g. is_typeArray() is true) is sufficient for a
> large fraction of the problem.
>
More information about the hotspot-gc-dev
mailing list