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