RFR (S): 8183226: Remembered set summarization accesses not fully initialized java thread DCQS
stefan.johansson at oracle.com
Tue Jul 11 08:05:00 UTC 2017
On 2017-07-11 09:27, Thomas Schatzl wrote:
> 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
>>>> 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
>>> 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.
> http://cr.openjdk.java.net/~tschatzl/8183226/webrev.1_to_2/ (diff)
> http://cr.openjdk.java.net/~tschatzl/8183226/webrev.2/ (full)
More information about the hotspot-gc-dev