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.hol...@oracle.com
<mailto:david.hol...@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
