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

[Kim Barrett]

> On Mar 29, 2016, at 4:44 AM, Thomas Schatzl <thomas.schatzl at oracle.com> 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.
>> 
>> I've run out of steam for looking at g1ConcurrentMark.cpp changes for
>> now.  I may have more comments there later.  I like the new approach
>> though. 
>> 

> Thanks for your very extensive review :) As you noticed I deferred the
> actual fixes to JDK-8151386, as almost all of these suggestions here
> would conflict with that change. If you think I should fix and rebase
> everything in this CR, I propose we just merge JDK-8151386 into this
> CR.

Deferring to JDK-8151386 is fine.  I guess I should start reviewing that…

> Typically I do tend to first do the cleanups and then fix, but
> initially I did not actually intend to do more thorough cleanups in
> this area, and just focus on the performance aspect. However at this
> time it would be a non-trivial amount of work to change the order of
> these fixes, hence my proposal to merge JDK-8151386, so I hope this
> order is acceptable.

With the history for fixing 8077144 involving pretty much a complete reset
and redirect in the middle, it’s not surprising that things didn’t go the way
you would normally do things.