RFR: 8146009: "pure virtual method called" with using new GC logging mechanism

Thomas Stüfe 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:
>> Hi,
>> 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
>> 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
>>     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,
>>     Kirk

More information about the hotspot-runtime-dev mailing list