RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed

[Bengt Rutisson]

Hi again,

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:
>>
>> Full:
>> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~kbarrett/8069367/webrev.01.incr/
>>
>> 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 
> reclaimed.

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?

Thanks,
Bengt

>
> Thanks,
> Bengt
>
>>
>>
>