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