RFR: 8146009: "pure virtual method called" with using new GC logging mechanism
thomas.stuefe at gmail.com
Thu Jan 21 17:00:40 UTC 2016
On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com <kirk at kodewerk.com>
> > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com>
> > 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
> Can I ask a silly question? If the JVM is shutting down is there a need to
> de-initialize logging?
I wonder too. Why not let the logging live right to the end? Logging is
useful in all life phases of the VM; if logging is disabled before
initialization or after cleanup, if one does not see output one always
wonders if logging is disabled or if we just did not hit the logging call.
Instead of deleting or disabling the LogOutput objects, why not just flush
them (to ensure they write all accumulated output) but let them live on? As
far as I can see, all LogOutput childs are keeping file descriptors which
get closed automatically once the process stops.
Or am I missing something obvious?
Kind Regards, Thomas
> IME iit is highly unlikely that the loss of one or two GC log records
> would make a difference in my use cases.
> Kind regards,
More information about the hotspot-runtime-dev