Hi Harold,
On 12/05/2020 10:49 pm, Harold Seigel wrote:
Hi David,
Thanks for looking at this.
This change disables logging and issuing a warning for any errors in the
-Xlog arguments that currently cause the JVM to terminate. For which
particular bad -Xlog arguments do you think this is a bad idea?
All of them! Unified Logging has always been fail-fast when it comes to
the log configuration settings. I think that is a good design and
certainly not something we should do a complete about-face on just
because of one reported issue!
My basic reaction to this issue now is that it is a "won't fix". Yes UL
behaves differently compared to the old GC logging flags - so be it.
At the very most we might consider making the inability to open the log
file a non-fatal error, but even then I'm more inclined to fail-fast so
that people realize they have set things up incorrectly rather than
allowing mistakes to go undetected.
This is also something that would need discussing at hotspot level
rather than just runtime & serviceability.
Cheers,
David
-----
Are there some bad -Xlog arguments where you think this would be a good
thing to do?
I agree that if we decide to do this, a CSR is needed.
Thanks, Harold
On 5/12/2020 3:32 AM, David Holmes wrote:
Hi Harold,
On 9/05/2020 3:22 am, Harold Seigel wrote:
Hi,
Please review this fix for JDK-8244105. The fix continues program
execution even when specified logging options are invalid.
Previously, invalid logging options terminated the program. Now, a
warning is issued. For example:
> java -Xlog:"gc*:file=/dont/exist" -version
[0.001s][error][logging] Error opening log file '/dont/exist': No
such file or directory
[0.001s][error][logging] Initialization of output 'file=/dont/exist'
using options '(null)' failed.
Java HotSpot(TM) 64-Bit Server VM warning: Invalid -Xlog option
'-Xlog:gc*:file=/dont/exist', see error log for details.
java version "15-internal" 2020-09-15
Java(TM) SE Runtime Environment (fastdebug build
15-internal+0-2020-05-08-1313404.hseigel.bug8244105)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build
15-internal+0-2020-05-08-1313404.hseigel.bug8244105, mixed mode,
sharing)
But if I am reading this correctly you are now only issuing a warning
and disabling logging if there are any errors of any kind in the -Xlog
arguments! That is not desirable IMO and a significant change in
behaviour.
Even just changing the behaviour in relation to a non-existent log
file will require a CSR request.
Thanks,
David
-----
Open Webrev:
http://cr.openjdk.java.net/~hseigel/bug_8244105/webrev/index.html
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8244105
The fix was regression tested by running Mach5 tiers 1 and 2 tests
and builds on Linux-x64, Solaris, Windows, and Mac OS X and by
running Mach5 tiers 3-5 tests on Linux-x64.
Thanks, Harold
