Just a note - unified logging belongs to runtime. thanks, Karen
> On Dec 6, 2017, at 1:33 AM, David Holmes <david.hol...@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: > > 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
