Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

David Holmes david.holmes at oracle.com
Fri Dec 1 00:48:07 UTC 2017


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
> 


More information about the hotspot-runtime-dev mailing list