Review request 6985422: flush the output streams before OnError commands

[Chuck Rasbold]

On Mon, Sep 20, 2010 at 4:58 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Chuck Rasbold said the following on 09/21/10 04:15:
>
>  The "aborting" that ostream_abort() does is to flush and merge the
>> LogCompilation files.  That behavior is what we desire before OnError
>> commands are processed.
>>
>
> flush I can understand.
>
>
>  I could factor out an ostream_flush() function, but ithere's no place we'd
>> want to call it.
>>
>> So is this OK?
>>
>> http://cr.openjdk.java.net/~rasbold/6985422/webrev.00
>>
>
> Yes, in that calling ostream_abort() a second time in os::shutdown will be
> a no-op.
>
> My only lingering concern is that while one thread is reporting this fatal
> error the rest of the VM continues to execute, and those other threads might
> encounter a stream/log-file that has now been closed. I don't know if this
> would be handled gracefully or whether we care one way or the other. We have
> the same issue with the ostream_abort in os::shutdown but the window between
> closing the files and blowing away the process is very small. In this case
> your onError commands could take an indeterminate amount of time during
> which the rest of the VM continues to execute.
>

Certainly, the OnError commands may take indeterminate amount of time. And I
admit that any OnError command, because it is run by "sh", will dominate any
tiny window between ostream_abort and the end of os:;shutdown().

However, the nature of OnError is that it gives the user one last chance to
attempt some processing.

In my user's case, he loses access to the files when the JVM dies. The
LogCompilation information of a crash is lost if it isn't captured at
OnError time.  Compiles done after report_and_die() is called are of little
interest compared to the compiler state when the error happens.

-- Chuck


> David
>
>  -- Chuck
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100923/6225b5da/attachment.html