Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput

Man Cao manc at google.com
Fri Dec 1 01:15:35 UTC 2017


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 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.

Thanks,
Man

On Thu, Nov 30, 2017 at 4:48 PM, David Holmes <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:
>
>> 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