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

[Staffan Larsen]

> On 22 jan. 2016, at 13:21, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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.

Cleaning up like this is important if the JVM is being run many time inside the same host process (think applets within a browser), but this is becoming much less common. I wonder if it works at all at this point.


> 
> David
> ------
> 
>> 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
>> 
>>