RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output

[Jesper Wilhelmsson]

Den 21/6/16 kl. 22:08, skrev Dmitry Fazunenko:
> Hi Jesper,
>
> New decorations look very attractive!
> But this change misses a regression test. Would either develop it or submit a CR
> to develop it later.

Yes, a regression test should be added.
Thanks,
/Jesper

>
> Thanks,
> Dima
>
>
> On 21.06.2016 22:09, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Please review this change to make -XX:+PrintFlagsFinal distinguish between
>> flags changed on the command line and flags changed by the ergonomics.
>>
>> To enable us to remember if a flag was set on the command line or not after
>> having been changed by the ergonomics I use another bit in the Flag struct.
>>
>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary
>> and I'm open to suggestions (bike sheding) about how to visualize this the best.
>>
>> The old decorations are:
>>
>> ' =' - Default value (no decoration)
>> ':=' - Value was changed, either by command line or ergonomics or other
>>
>> The new decorations are:
>>
>> ' =' - Default value (no decoration)
>> ':=' - Set on the command line
>> '?=' - Changed by the ergonomics
>> '!=' - Set on the command line AND changed by the ergonomics
>> '-=' - Any other origin, like changed by management API or taken from a config
>> file
>>
>> My reasoning behind selecting these characters are that ':=' looks like a
>> solid assignment and will therefore represent the command line. You never know
>> what you get from the ergonomics, so '?=' seems appropriate. '!=' because
>> you'd want to know that the ergonomics changed a value you had set on the
>> command line.
>>
>> Another option could be to use a colon ':=' for the command line, and a comma
>> ',=' for the ergonomics. That would naturally give us the semi-colon ';=' for
>> something set on the command line and changed by the ergonomics. I didn't go
>> with this because the colon and semi-colon can be hard to distinguish from
>> each other.
>>
>> As mentioned above there are other origins, the enum contains eight values.
>> There is no mention of the other types in the bug and there are no is_...()
>> for the other types in globals.cpp, so they didn't seem as important. If the
>> general opinion is that these other origins are as important, or we might as
>> well..., I'd suggest that we use letters as decorations. Let me know if you
>> have an opinion.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/
>>
>> Thanks,
>> /Jesper
>