RFR: 8142979: Add programmatic enable/disable methods to Unified Logging

[David Holmes]

On 10/12/2015 7:12 PM, Marcus Larsson wrote:
> Hi,
>
> On 2015-12-10 06:08, David Holmes wrote:
>> On 10/12/2015 4:52 AM, Marcus Larsson wrote:
>>> Hey Max,
>>>
>>> On 2015-12-09 18:11, Max Ockner wrote:
>>>> Hello Marcus,
>>>>
>>>> I looked over your code in logConfiguration.cpp
>>>>
>>>> What is the purpose of limiting the number of tags that can be
>>>> configured through a given call to configure_stdout? I understand that
>>>> previously any change made to the configuration would have reset it
>>>> entirely, and as a result you could restrict the number of tags in the
>>>> configuration.  I can't tell if you want to restrict the number of
>>>> tags in the configuration or the number of tags processed by
>>>> configure_stdout, because those restrictions are no longer equivalent
>>>> now that you can configure_stdout can add to the configuration without
>>>> clearing it.
>>>
>>> A call to configure_stdout will configure logging for a particular
>>> tagset. It doesn't configure a bunch of tags separately. What I mean by
>>> this is that LogConfigure::configure_stdout(LogLevel::Info, true,
>>> LOG_TAGS(tag1, tag2)) is equivalent to the vm argument
>>> -Xlog:tag1+tag2=info. It is not the same as -Xlog:tag1=info,tag2=info
>>> (or alternatively -Xlog:tag1=info -Xlog:tag2=info).
>>
>> Sorry have to ask: what is the difference between these three variants:
>>
>> -Xlog:tag1+tag2=info
>
> This will enable messages tagged with tag1 *and* tag2, like for example:
>
> log_info(tag1, tag2)("msg");
>
> Messages tagged with only one of these tags will not be configured.

Ah I see. Where does the end user find out about this?

Thanks,
David
-----


>> -Xlog:tag1=info,tag2=info
>> -Xlog:tag1=info -Xlog:tag2=info
>>
>> I can't see a description of the + version, but I assume the bototm
>> two are equivalent?
>
> Yes, these two are equivalent now. They enable messages tagged either
> with tag1 *or* tag2. It doesn't enable the combination of the two.
>
> Regards,
> Marcus
>
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> Marcus
>>>
>>>>
>>>> This question also applies to the handling of multiple Xlog options.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>> On 12/1/2015 3:03 AM, Marcus Larsson wrote:
>>>>>
>>>>>
>>>>> On 2015-11-30 19:40, Coleen Phillimore wrote:
>>>>>>
>>>>>> I'm confused how this API works.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mockner/classunload/src/share/vm/prims/jvmtiEnv.cpp.sdiff.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> I imagine we'd want to do:
>>>>>>
>>>>>> if (value != 0) {
>>>>>>   LogConfiguration::configure_stdout(info, true, classunload);
>>>>>> } else {
>>>>>>   LogConfiguration::configure_stdout(off, true, classunload);
>>>>>> }
>>>>>>
>>>>>> ???
>>>>>
>>>>> Yes, except you would need to pass the classunload tag with the
>>>>> LOG_TAGS macro, so it'd be:
>>>>>
>>>>> if (value != 0) {
>>>>>   LogConfiguration::configure_stdout(LogLevel::Info, true,
>>>>> LOG_TAGS(classunload));
>>>>> } else {
>>>>>   LogConfiguration::configure_stdout(LogLevel::Off, true,
>>>>> LOG_TAGS(classunload));
>>>>> }
>>>>>
>>>>> and that would be the same as passing -Xlog:classunload=info and
>>>>> -Xlog:classunload=off
>>>>>
>>>>> Regards,
>>>>> Marcus
>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>> On 11/25/15 7:13 AM, Marcus Larsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the following patch adding support for configuration
>>>>>>> of the stdout unified logging output from within the VM itself.
>>>>>>>
>>>>>>> The patch adds the configure_stdout() function, allowing a set of
>>>>>>> tags to be set to the given level on stdout.
>>>>>>> To disable logging the level is simply specified as LogLevel::Off.
>>>>>>>
>>>>>>> The patch depends on the fix for 8142952 [0] that's currently out
>>>>>>> on review, so the configuration is correctly aggregated rather than
>>>>>>> reset.
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mlarsson/8142979/webrev.00/
>>>>>>>
>>>>>>> Issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8142979
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marcus
>>>>>>>
>>>>>>> [0]: https://bugs.openjdk.java.net/browse/JDK-8142952
>>>>>>
>>>>>
>>>>
>>>
>