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

Bengt Rutisson bengt.rutisson at oracle.com
Thu Mar 12 08:32:50 UTC 2015

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 



More information about the hotspot-gc-dev mailing list