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

[Stefan Johansson]

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
>>>> 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)
Looks good,
StefanJ
> Thanks,
>    Thomas
>