RFR (S): 8183226: Remembered set summarization accesses not fully initialized java thread DCQS

[Thomas Schatzl]

Hi again,

On Mon, 2017-07-10 at 14:15 +0200, Thomas Schatzl wrote:
> Hi Erik (and Stefan),
> 
>   thanks for your review.
> 
> On Fri, 2017-07-07 at 13:16 +0200, Erik Helin wrote:
> > 
> > On 07/03/2017 02:12 PM, Thomas Schatzl wrote:
> > >   can I get reviews for the following change that breaks some
> > > dependency cycle in g1remset initialization to fix some (at this
> > > time benign) bug when printing remembered set summarization
> > > information?
> > > 
> > > The problem is that G1Remset initializes its internal remembered
> > > [...]
> > You don't need to do all the cleanups, but I think having a fully 
> > functioning default constructor is a better way to solve this
> > problem, rather than shuffling the call to initialize around. What
> > do
> > you think?
> Let's defer the other suggested cleanups to a different CR.
> 
> In the following webrev I also added StefanJ's suggestion to extract
> concurrent refinement initialization into a separate method.
> (I do not really understand why that method is actually returning an
> error code: all error conditions in ConcurrentG1Refine call
> vm_shutdown_during_initialization() anyway - even that seems
> superfluous: failing to allocate memory shuts down the VM already).
> 
> Webrevs:
> http://cr.openjdk.java.net/~tschatzl/8183226/webrev.0_to_1/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8183226/webrev.1/ (full)
> 

Erik pointed out that by having two constructors, one taking a
G1RemSet, we can save a few more lines of code, avoiding the
G1RemSetSummary::initialize() method completely. :)

Here is an implementation of this idea.

Webrevs:
http://cr.openjdk.java.net/~tschatzl/8183226/webrev.1_to_2/ (diff)
http://cr.openjdk.java.net/~tschatzl/8183226/webrev.2/ (full)

Thanks,
  Thomas