Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

Man Cao
Hello,

We (Java Platform Team at Google) found that in JDK9, the file generated by
-XX:+LogVMOutput no longer contains GC log messages, because the unified
JVM logging framework does not use the defaultStream and fileStream classes
and the tty variable. Similarly, related options such as LogFile,
DisplayVMOutput have no effect on the messages printed by the unified
logging framework.

The main problem for us is that most of our production Java servers use the
options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and
other VM messages. These flags would no longer work for JDK9's JVM logging
framework. In addition, the file generated by -XX:+LogVMOutput may contain
information that is not printed by the unified logging framework.

What is worse is that if LogFile and the output of unified logging
framework point to the same file, the file may contain partial or corrupted
messages from the unified logging framework. For example, consider the
following command:

java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
-XX:LogFile=test.log

Then test.log would miss some of the messages that would be printed at the
beginning if you run "java -Xlog".

So our questions are:
1. Do you consider this is a bug for the unified logging framework that
should be fixed? Should the unified logging framework respect these
diagnostic options?

2. Is there a plan to deprecate these diagnostic options (LogVMOutput,
LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream classes
and the tty variable eventually removed from HotSpot?

Thanks,
Man
Reply | Threaded
Open this post in threaded view
|

Re: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

David Holmes
Hi Man,

Adding serviceability as UL is a serviceability feature.

On 1/12/2017 10:23 AM, Man Cao wrote:

> Hello,
>
> We (Java Platform Team at Google) found that in JDK9, the file generated by
> -XX:+LogVMOutput no longer contains GC log messages, because the unified
> JVM logging framework does not use the defaultStream and fileStream classes
> and the tty variable. Similarly, related options such as LogFile,
> DisplayVMOutput have no effect on the messages printed by the unified
> logging framework.
>
> The main problem for us is that most of our production Java servers use the
> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and
> other VM messages. These flags would no longer work for JDK9's JVM logging
> framework. In addition, the file generated by -XX:+LogVMOutput may contain
> information that is not printed by the unified logging framework.
>
> What is worse is that if LogFile and the output of unified logging
> framework point to the same file, the file may contain partial or corrupted
> messages from the unified logging framework. For example, consider the
> following command:
>
> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
> -XX:LogFile=test.log
>
> Then test.log would miss some of the messages that would be printed at the
> beginning if you run "java -Xlog".
>
> So our questions are:
> 1. Do you consider this is a bug for the unified logging framework that
> should be fixed? Should the unified logging framework respect these
> diagnostic options?

My understanding is that UL is intended to replace the legacy "logging"
flags and works independently of them. So no, UL should not respect
these flags.

> 2. Is there a plan to deprecate these diagnostic options (LogVMOutput,
> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream classes
> and the tty variable eventually removed from HotSpot?

I believe that is the general intent - though complete removal is not
feasible as UL can't always be used in all contexts. We have migrated
various subsystems to UL and all new logging should be using UL. However
I don't believe we actually have active RFEs to aggressively complete
the switchover.

Just my 2c.

David

> Thanks,
> Man
>
Reply | Threaded
Open this post in threaded view
|

Re: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

Man Cao
Thanks David for the quick response!

Yes, I understand completely removing defaultStream and tty is probably
infeasible.

If deprecating the diagnostic options (LogVMOutput, LogFile,
DisplayVMOutput) is the intent, could someone create a bug/RFE to track it?
They should probably first be added to the special_jvm_flags table in
arguments.cpp, so there will be a warning when people use them. The case of
conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a
concern, the JVM should at least issue a warning about it. In addition, it
would make it easier for us to convince production teams to stop using
these options.

Thanks,
Man

On Thu, Nov 30, 2017 at 4:48 PM, David Holmes <[hidden email]>
wrote:

> Hi Man,
>
> Adding serviceability as UL is a serviceability feature.
>
>
> On 1/12/2017 10:23 AM, Man Cao wrote:
>
>> Hello,
>>
>> We (Java Platform Team at Google) found that in JDK9, the file generated
>> by
>> -XX:+LogVMOutput no longer contains GC log messages, because the unified
>> JVM logging framework does not use the defaultStream and fileStream
>> classes
>> and the tty variable. Similarly, related options such as LogFile,
>> DisplayVMOutput have no effect on the messages printed by the unified
>> logging framework.
>>
>> The main problem for us is that most of our production Java servers use
>> the
>> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and
>> other VM messages. These flags would no longer work for JDK9's JVM logging
>> framework. In addition, the file generated by -XX:+LogVMOutput may contain
>> information that is not printed by the unified logging framework.
>>
>> What is worse is that if LogFile and the output of unified logging
>> framework point to the same file, the file may contain partial or
>> corrupted
>> messages from the unified logging framework. For example, consider the
>> following command:
>>
>> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput
>> -XX:LogFile=test.log
>>
>> Then test.log would miss some of the messages that would be printed at the
>> beginning if you run "java -Xlog".
>>
>> So our questions are:
>> 1. Do you consider this is a bug for the unified logging framework that
>> should be fixed? Should the unified logging framework respect these
>> diagnostic options?
>>
>
> My understanding is that UL is intended to replace the legacy "logging"
> flags and works independently of them. So no, UL should not respect these
> flags.
>
> 2. Is there a plan to deprecate these diagnostic options (LogVMOutput,
>> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream
>> classes
>> and the tty variable eventually removed from HotSpot?
>>
>
> I believe that is the general intent - though complete removal is not
> feasible as UL can't always be used in all contexts. We have migrated
> various subsystems to UL and all new logging should be using UL. However I
> don't believe we actually have active RFEs to aggressively complete the
> switchover.
>
> Just my 2c.
>
> David
>
> Thanks,
>> Man
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

David Holmes
On 1/12/2017 11:15 AM, Man Cao wrote:
> Thanks David for the quick response!
>
> Yes, I understand completely removing defaultStream and tty is probably
> infeasible.
>
> If deprecating the diagnostic options (LogVMOutput, LogFile,
> DisplayVMOutput) is the intent, could someone create a bug/RFE to track
> it? They should probably first be added to the special_jvm_flags table

I think there is too much yet to be done in the conversion process to
file such a RFE - to be frank we don't have active RFE's for the
remaining conversions, rather they are being tackled case by case when
people are working in the area.

> in arguments.cpp, so there will be a warning when people use them. The
> case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is
> also a concern, the JVM should at least issue a warning about it. In
> addition, it would make it easier for us to convince production teams to
> stop using these options.

I have filed:

https://bugs.openjdk.java.net/browse/JDK-8193117

JDK-8193117 Issue a warning if legacy logging and Unified Logging are
told to use the same file

Cheers,
David
-----

> Thanks,
> Man
>
> On Thu, Nov 30, 2017 at 4:48 PM, David Holmes <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Man,
>
>     Adding serviceability as UL is a serviceability feature.
>
>
>     On 1/12/2017 10:23 AM, Man Cao wrote:
>
>         Hello,
>
>         We (Java Platform Team at Google) found that in JDK9, the file
>         generated by
>         -XX:+LogVMOutput no longer contains GC log messages, because the
>         unified
>         JVM logging framework does not use the defaultStream and
>         fileStream classes
>         and the tty variable. Similarly, related options such as LogFile,
>         DisplayVMOutput have no effect on the messages printed by the
>         unified
>         logging framework.
>
>         The main problem for us is that most of our production Java
>         servers use the
>         options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC
>         logs and
>         other VM messages. These flags would no longer work for JDK9's
>         JVM logging
>         framework. In addition, the file generated by -XX:+LogVMOutput
>         may contain
>         information that is not printed by the unified logging framework.
>
>         What is worse is that if LogFile and the output of unified logging
>         framework point to the same file, the file may contain partial
>         or corrupted
>         messages from the unified logging framework. For example,
>         consider the
>         following command:
>
>         java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions
>         -XX:+LogVMOutput
>         -XX:LogFile=test.log
>
>         Then test.log would miss some of the messages that would be
>         printed at the
>         beginning if you run "java -Xlog".
>
>         So our questions are:
>         1. Do you consider this is a bug for the unified logging
>         framework that
>         should be fixed? Should the unified logging framework respect these
>         diagnostic options?
>
>
>     My understanding is that UL is intended to replace the legacy
>     "logging" flags and works independently of them. So no, UL should
>     not respect these flags.
>
>         2. Is there a plan to deprecate these diagnostic options
>         (LogVMOutput,
>         LogFile, DisplayVMOutput, etc.)? Will the defaultStream,
>         fileStream classes
>         and the tty variable eventually removed from HotSpot?
>
>
>     I believe that is the general intent - though complete removal is
>     not feasible as UL can't always be used in all contexts. We have
>     migrated various subsystems to UL and all new logging should be
>     using UL. However I don't believe we actually have active RFEs to
>     aggressively complete the switchover.
>
>     Just my 2c.
>
>     David
>
>         Thanks,
>         Man
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

Karen Kinnear
Just a note - unified logging belongs to runtime.

thanks,
Karen

> On Dec 6, 2017, at 1:33 AM, David Holmes <[hidden email]> wrote:
>
> On 1/12/2017 11:15 AM, Man Cao wrote:
>> Thanks David for the quick response!
>> Yes, I understand completely removing defaultStream and tty is probably infeasible.
>> If deprecating the diagnostic options (LogVMOutput, LogFile, DisplayVMOutput) is the intent, could someone create a bug/RFE to track it? They should probably first be added to the special_jvm_flags table
>
> I think there is too much yet to be done in the conversion process to file such a RFE - to be frank we don't have active RFE's for the remaining conversions, rather they are being tackled case by case when people are working in the area.
>
>> in arguments.cpp, so there will be a warning when people use them. The case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a concern, the JVM should at least issue a warning about it. In addition, it would make it easier for us to convince production teams to stop using these options.
>
> I have filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8193117
>
> JDK-8193117 Issue a warning if legacy logging and Unified Logging are told to use the same file
>
> Cheers,
> David
> -----
>
>> Thanks,
>> Man
>> On Thu, Nov 30, 2017 at 4:48 PM, David Holmes <[hidden email] <mailto:[hidden email]>> wrote:
>>    Hi Man,
>>    Adding serviceability as UL is a serviceability feature.
>>    On 1/12/2017 10:23 AM, Man Cao wrote:
>>        Hello,
>>        We (Java Platform Team at Google) found that in JDK9, the file
>>        generated by
>>        -XX:+LogVMOutput no longer contains GC log messages, because the
>>        unified
>>        JVM logging framework does not use the defaultStream and
>>        fileStream classes
>>        and the tty variable. Similarly, related options such as LogFile,
>>        DisplayVMOutput have no effect on the messages printed by the
>>        unified
>>        logging framework.
>>        The main problem for us is that most of our production Java
>>        servers use the
>>        options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC
>>        logs and
>>        other VM messages. These flags would no longer work for JDK9's
>>        JVM logging
>>        framework. In addition, the file generated by -XX:+LogVMOutput
>>        may contain
>>        information that is not printed by the unified logging framework.
>>        What is worse is that if LogFile and the output of unified logging
>>        framework point to the same file, the file may contain partial
>>        or corrupted
>>        messages from the unified logging framework. For example,
>>        consider the
>>        following command:
>>        java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions
>>        -XX:+LogVMOutput
>>        -XX:LogFile=test.log
>>        Then test.log would miss some of the messages that would be
>>        printed at the
>>        beginning if you run "java -Xlog".
>>        So our questions are:
>>        1. Do you consider this is a bug for the unified logging
>>        framework that
>>        should be fixed? Should the unified logging framework respect these
>>        diagnostic options?
>>    My understanding is that UL is intended to replace the legacy
>>    "logging" flags and works independently of them. So no, UL should
>>    not respect these flags.
>>        2. Is there a plan to deprecate these diagnostic options
>>        (LogVMOutput,
>>        LogFile, DisplayVMOutput, etc.)? Will the defaultStream,
>>        fileStream classes
>>        and the tty variable eventually removed from HotSpot?
>>    I believe that is the general intent - though complete removal is
>>    not feasible as UL can't always be used in all contexts. We have
>>    migrated various subsystems to UL and all new logging should be
>>    using UL. However I don't believe we actually have active RFEs to
>>    aggressively complete the switchover.
>>    Just my 2c.
>>    David
>>        Thanks,
>>        Man