RFR: 8302073: Specifying OnError handler prevents WatcherThread to break a deadlock in report_and_die()

[Thomas Stuefe]

On Wed, 8 Mar 2023 20:09:38 GMT, jsolomon8080 <duke at openjdk.org> wrote:

> Hi - I'm the originator of this bug report. I'm glad this is getting fixed and I will ultimately defer to the java experts since I have never contributed code to this code base, but if it were me, I'd do the simplest thing possible. The solution presented here seems overly complex. I don't understand why an OnError script or an abort_hook is so special. I think it's up to the user to ensure that neither takes longer than ErrorLogTimeout, which defaults to 2 minutes. That's an eternity. Do java users really expect to wait 2 minutes for their processes to exit?

Some do, some don't, there are cases for both. But that is not the point. We must guarantee that all OnError commands are run and that the abort hook is called. Since these things happen after error reporting, we cannot interrupt error reporting.

This is a backward compatibility question. There are arguments for ErrorLogTimeout having precedence, and there are arguments for the current behavior. Both sides have good arguments, but OpenJDK tries to err on the side of compatibility here.

> If this were my code, I would remove any guarantee about OnError and make it responsibility of the user to set ErrorLogTimeout appropriately.

Nothing is stopping Azul from changing this behavior downstream in their VM, but upstream we need to find a consensus with all interested parties.

> 
> I understand that there may be many users who have counted on this guarantee and you can't break them now. I also understand that I'm not aware of all the ways that OnError is used. I'm sure we will get to some solution that will fix the real problem, which I care about the most. Thank you.

Let's see if this issue is moot once the fix for JDK-8303861 is out.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/12925