On 22/01/2016 3:00 AM, Thomas Stüfe wrote:
Hi,
On Wed, Jan 20, 2016 at 2:01 PM, k...@kodewerk.com
<mailto:k...@kodewerk.com> <k...@kodewerk.com
<mailto:k...@kodewerk.com>> wrote:
> On Jan 20, 2016, at 5:20 AM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@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.
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
