Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput
david.holmes at oracle.com
Wed Dec 6 06:33:59 UTC 2017
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
> 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:
JDK-8193117 Issue a warning if legacy logging and Unified Logging are
told to use the same file
> 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:
> We (Java Platform Team at Google) found that in JDK9, the file
> generated by
> -XX:+LogVMOutput no longer contains GC log messages, because the
> 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
> 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
> 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
> 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.
More information about the hotspot-runtime-dev