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

[Thomas Schatzl]

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.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-
> 

JDK-8152938.

Thanks,
  Thomas