On 19/01/2016 11:58 PM, Marcus Larsson wrote:
Hi,
Please review the following patch to fix an issue in UL causing the VM
to crash during shutdown.
The problem is that the static LogStdoutOutput is deinitialized before
the last use of it (G1 concurrent thread tries to log very late during
VM shutdown). The solution is to make sure neither LogStdoutOutput nor
LogStderrOutput are deinitialized during the full lifetime of the VM. To
I agree with Kim here - this seems like the "wrong" solution. If the G1
thread can log very late during VM shutdown then we could
- move the logging "deinitialize" to later in the shutdown process
(assuming the G1 threads won't continue to run right up to process
termination); or
- ensure the G1 threads have to terminate, or block, before the
deinitialization
Generally termination coordination involves the use of locks unfortunately.
That said, pre-UL, would the "logging" in the G1 thread have hit any
termination issues or was the logging target valid through the lifetime
of the VM?
accomplish this I've changed the storage from static objects to static
pointers to heap instances that are allocated & initialized on first use
I'm not familiar with the initialization of function-scoped statics but
as Kim noted the thread-safety aspects of this seem dubious at best.
That aside, I have concerns about non-trivial static initialization in
the existing code, as it is unclear to me exactly when during VM
initialization such instances will be constructed.
Thanks,
David
-----
[0]. These instances are never deleted and can always be used. Also
updated LogConfiguration::finalize to disable all file outputs before
deleting & freeing them.
Webrev:
http://cr.openjdk.java.net/~mlarsson/8146009/webrev.00/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8146009
Testing:
- local runs of the reproducer (500+ iterations without crashing)
- JPRT
Thanks,
Marcus
[0]: https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
