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 <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> 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
> 
>