RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed
bengt.rutisson at oracle.com
Thu Mar 12 10:19:41 UTC 2015
On 2015-03-12 09:32, Bengt Rutisson wrote:
> Hi Kim and Thomas,
> On 2015-03-11 22:16, Kim Barrett wrote:
>> Here’s the new webrev:
>> I haven’t done a full Aurora performance run with this new version,
>> but the synthetic benchmark
>> Thomas gave me isn’t showing any degradation. (In fact, once again
>> today, the new version
>> is running a tiny bit faster on that benchmark, e.g. the real
>> difference is pretty much in the noise.)
> I've been thinking a bit about the approach to solve the mark issue
> and I have to admit that I don't really have a good feeling about how
> this is currently solved. The eager reclamation knowledge is leaked in
> to a lot of places and we don't have any explicit way of checking what
> has actuallly happened. All we can do is guess that it was eager
> reclamation that caused things to look in unexpected ways. To me this
> is very fragile an might even hide other real problems that cause
> similar symptoms.
> Can we find some other way of handling this more explicitly?
> One thought I had was if we can note the fact that we push a humongous
> object on to a mark stack. Then the young GC can just check if any
> mark stack contains a humongous object and in that case either skip
> reclaiming that object or go and fix the mark stack after it has been
I talked a bit to Mikael and StefanK about this.
A more stable approach that would actually allow us to enforce the SATB
invariant might be to:
1) Change G1FreeHumongousRegionClosure::doHeapRegion() to not reset the
mark value for a humongous object but instead skip reclaiming objects
that have the mark set.
2) Make the SATB filtering (ObjPtrQueue::filter()) note when a humongous
object is pushed on a SATB queue. This information can be stored in a
separate strucuture. The G1FreeHumongousRegionClosure::doHeapRegion()
would have to look at this structure and avoid reclaiming any humongous
objects that have appeared on the SATB queues. Not sure, but maybe this
structure could be the HumongousIsLiveBiasedMappedArray that we already
have. That is, when the SATB filtering detects a humongous object it
will mark it as live in the HumongousIsLiveBiasedMappedArray.
What do you think about this? Is it doable?
More information about the hotspot-gc-dev