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
reclaimed.
Thanks,
Bengt
>
>
More information about the hotspot-gc-dev
mailing list