RFR (M): 8077144: Concurrent mark initialization takes too long
thomas.schatzl at oracle.com
Tue Mar 29 09:34:25 UTC 2016
On Tue, 2016-03-29 at 10:44 +0200, Thomas Schatzl wrote:
> 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.2_to_3/ (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-
More information about the hotspot-gc-dev