David, On Fri, Jan 22, 2016 at 1:21 PM, 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. > > 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. Thomas 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 >> >> >>
