RFR (M): 8077144: Concurrent mark initialization takes too long (original) (raw)

Thomas Schatzl thomas.schatzl at oracle.com
Tue Mar 29 09:34:25 UTC 2016

Hi,

On Tue, 2016-03-29 at 10:44 +0200, Thomas Schatzl wrote:

Hi,

On Fri, 2016-03-25 at 21:38 -0400, Kim Barrett wrote: > > On Mar 15, 2016, at 6:12 PM, Thomas Schatzl <_ _> > thomas.schatzl at oracle.com> wrote: > > > > Hi Mikael, > > > >

> > updated webrev at > > http://cr.openjdk.java.net/~tschatzl/8077144/webrev.3/ (full) > > http://cr.openjdk.java.net/~tschatzl/8077144/webrev.2to3/ (diff > > ) > > > > which implements the suggested changes. >

> [Pre-existing] > abort() also clears the nextMarkBitMap, but appears to do so in > STW. > Seems like one of those is superfluous. And wouldn't it be better > to not do any of these in (STW) abort() but rather do all of them > here?

Abort() can only occur in full gc, so the extra card bitmap clear does not matter much. Also, the existing marking "state" machine assumes that after full gc the bitmaps/card live data is clear, so this would need extensive changes there. Further, this would also mean that after a full gc G1 can't immediately start marking, as it needs to clear this information first, possibly leading to another full gc right away (in border conditions) because it does take some time.

Not saying that this is a bad idea, because actually lazily allocating needed parts of the mark bitmap (and lazily clearing these parts) is not a bad idea.

Kind of saying, that I do not see this problem part of this change.

I filed JDK-

JDK-8152938.

Thanks, Thomas

More information about the hotspot-gc-dev mailing list