RFR (M): 8077144: Concurrent mark initialization takes too long
thomas.schatzl at oracle.com
Wed Mar 9 17:05:26 UTC 2016
please hold off reviewing this.
I thought of a very good alternative that removes the need for all
these auxiliary data structures, and need some time for performance
Note that would also obsolete 8151069, but not 8151126 (with some
On Tue, 2016-03-08 at 17:20 +0100, Thomas Schatzl wrote:
> Hi all,
> there is a new webrev at
> http://cr.openjdk.java.net/~tschatzl/8077144/webrev.1 (full)
> http://cr.openjdk.java.net/~tschatzl/8077144/webrev.0_to_1 (diff)
> which addresses all but one of the presented issues: there are no
> provisions to deal with deallocating that memory.
> This is a pre-existing issue I do not like to address as part of this
> change; the existing destructor just calls ShouldNotReachHere() too.
> When fixing this, support for releasing the data structures touched
> here can be added as well.
> A few of them will move out of G1ConcurrentMark in the near future
> anyway (JDK-8151386) or modify the data structures significantly (JDK
> Also, the name of the flag changed to be more generic, as there are
> plans to not only implement pre-touching of bitmaps.
> This change is based on the changes StefanK sent out for review
More information about the hotspot-gc-dev