RFR (S): 8200305: Update gc,liveness output with remset state after rebuild remset concurrently changes

[Stefan Johansson]

On 2018-04-04 12:40, Thomas Schatzl wrote:
> On Thu, 2018-03-29 at 15:50 +0200, Stefan Johansson wrote:
>> Hi,
>>
>> On 2018-03-28 20:35, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2018-03-28 at 11:18 -0700, sangheon.kim wrote:
>>>> Hi Thomas,
>>>>
>>>> On 03/28/2018 08:26 AM, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>      can I have reviews for this change that updates the
>>>>> gc,liveness output to add the remembered set state?
>>>>>
>>>>> This change adds a column next to "remset" called "state" that
>>>>> can be either UNTRA (Untracked), UPDAT (Updating) and CMPLT
>>>>> (Complete).
>>>>>
>>>>> There is a log snippet attached that shows the new output.
>>>>>
>>>>> If somebody asks, I kind of agree that we should probably
>>>>> rethink this output (remove some of the addresses, add region
>>>>> number), but this is imho out of scope for this change. ;]
>>>>>
>>>>> CR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8200305
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~tschatzl/8200305/webrev/
>>>>> Testing:
>>>>> local verification
>>>>
>>>> Looks good as is.
>>>>
>>>> Adding the state is a good idea.
>>>> But these short version strings are not easy to catch. Just
>>>> printing original strings(9 characters) are too long? :)
>>>>
>>>
>>>     yes, I am aware of this issue, I actually thought about this for
>>> an unusual amount of time too. After all I decided to keep the
>>> abbreviations. And I understand that particularly UNTRA vs. UPDAT
>>> might be a candidate for confusion, but then again it seemed better
>>> than the long strings.
>>>
>>> However if somebody else also prefers the long strings, I will
>>> change that without further delay.
>>
>> I'm fine either way, but an alternative, not sure it's better, could
>> be  to add a footer explaining the short names. In that case the
>> short name could be even shorter:
>> - = Untracked
>> + = Updating
>> # = Complete
>>
>> An other alternative is would be to revisit the state-names and
>> maybe come up with something only needing one state_string, but I
>> don't have  any ideas here. So I suggest going with either what you
>> have or the footer-approach.
> 
> I think I will go with what I have if you don't mind. A change that
> removes useless information from the output quite a bit is needed
> anyway.
I'm fine with that.

Thanks,
Stefan
> 
> Thanks,
>    Thomas
>