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

[Thomas Schatzl]

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.

Thanks,
  Thomas