RFR: 8146009: "pure virtual method called" with using new GC logging mechanism
thomas.stuefe at gmail.com
Sat Jan 23 09:18:21 UTC 2016
On Fri, Jan 22, 2016 at 1:21 PM, David Holmes <david.holmes at oracle.com>
> On 22/01/2016 3:00 AM, Thomas Stüfe wrote:
>> On Wed, Jan 20, 2016 at 2:01 PM, kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com> <kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com>> wrote:
>> > On Jan 20, 2016, at 5:20 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>> > 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
>> >> the last use of it (G1 concurrent thread tries to log very late
>> >> VM shutdown). The solution is to make sure neither LogStdoutOutput
>> >> 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?
> There is an ideal (which we seem to get further and further from) that the
> JVM should be unloadable within a process. In that model everything we
> initialize we should "de-initialize" before termination. And when logging
> itself can depend on facilities that are themselves "torn down" during
> termination we can have problems in trying to log too late, just as we can
> trying to log too early.
Ok, I agree with you. Both on the long term goal of being unloadable and
that the logging system needs other subsystems (e.g thread locals) which
need to be life too.
> 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