RFR (S): 8183226: Remembered set summarization accesses not fully initialized java thread DCQS
thomas.schatzl at oracle.com
Tue Jul 11 07:27:54 UTC 2017
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).
> 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.
More information about the hotspot-gc-dev