RFR: 8146009: "pure virtual method called" with using new GC logging mechanism
david.holmes at oracle.com
Wed Jan 20 04:20:34 UTC 2016
On 19/01/2016 11:58 PM, Marcus Larsson wrote:
> 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
- ensure the G1 threads have to terminate, or block, before the
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.
> . These instances are never deleted and can always be used. Also
> updated LogConfiguration::finalize to disable all file outputs before
> deleting & freeing them.
> - local runs of the reproducer (500+ iterations without crashing)
> - JPRT
> : https://isocpp.org/wiki/faq/ctors#static-init-order-on-first-use
More information about the hotspot-runtime-dev