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

[Marcus Larsson]

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.

> -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
>>>>>
>>>>
>>>
>>