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

Marcus Larsson marcus.larsson at oracle.com
Mon Dec 14 15:56:52 UTC 2015


On 2015-12-11 18:44, Max Ockner wrote:
> Marcus,
> Did you do any testing for this change? I couldn't tell from your 
> webrev or email.

I did a JPRT run to verify that it compiles everywhere, but didn't test 
it further than that. It would be great to have a unit test for this. 
Although I'm not sure if I should write it as an InternalVMTest now, or 
wait for proper unit test support and write one that will be integrated 
together with the other unit tests I have lying around for UL.

Regards,
Marcus

> Thanks,
> Max
>
> On 12/10/2015 8:15 AM, Marcus Larsson wrote:
>>
>> On 2015-12-10 11:28, David Holmes wrote:
>>> 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?
>>
>> Currently I think it's only described in the JEP.
>>
>> It should probably be explained better in the -Xlog:help output.
>>
>> Regards,
>> Marcus
>>
>>
>>>
>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>



More information about the hotspot-runtime-dev mailing list