Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput
karen.kinnear at oracle.com
Wed Dec 6 14:17:47 UTC 2017
Just a note - unified logging belongs to runtime.
> 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:
> 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