[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Unified JVM Logging and diagnostic options LogVMOutput, LogFile,  DisplayVMOutput
From:       Karen Kinnear <karen.kinnear () oracle ! com>
Date:       2017-12-06 14:17:47
Message-ID: 4B8D1CCD-50DF-4A13-8C04-9B3B4646781F () oracle ! com
[Download RAW message or body]

Just a note - unified logging belongs to runtime.

thanks,
Karen

> On Dec 6, 2017, at 1:33 AM, David Holmes <david.holmes@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@oracle.com \
> > <mailto:david.holmes@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


[prev in list] [next in list] [prev in thread] [next in thread]