RFR: 8288984: Simplification in Shutdown.exit [v2]

[David Holmes]

On Mon, 4 Jul 2022 08:07:25 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Runtime.java line 89:
>> 
>>> 87:      * of the first invocation will be used; the status codes from other invocations
>>> 88:      * will be ignored. If this method is invoked from a shutdown hook the system
>>> 89:      * will deadlock.
>> 
>> Is "deadlock" accurate?  I thought Java monitors were reentrant, with the result that a shutdown hook calling `exit` would lead to a recursive `runHooks` which would run all the hooks, including *rerunning* hooks before the one that called exit (which could be bad), and then rerunning the hook that called exit (possibly leading to infinite recursion), then running later hooks, then returning to rerun those later hooks.  This situation could be made perhaps less bad by having runHooks null out each entry in the hooks table before it runs that hook, or using currentRunningHook to determine which hooks to run in runHooks.  Or something else, like immediate exit in this case.  (That would be spec change.)
>
>> Is "deadlock" accurate?
> 
> Yes.
> 
> In the context of the specification, "shutdown hook" means _application_ shutdown hook - as far as the specification is concerned, application shutdown hooks are the only kind of hooks. Right?
> 
> For example, the following will deadlock (when run with the changes in this PR):
> 
> 
> public class TestHook {
>   public static void main(String... arg) {
>     Thread hook = new Thread("my-hook") {
>       @Override
>       public void run() {
>         System.exit(1);
>       }
>     };
>     Runtime.getRuntime().addShutdownHook(hook);
>     System.exit(0);
>   }
> }

It is a general deadlock, not a monitor based deadlock: the thread that called exit and holds the lock has to join() the hook thread. The hook thread blocks on the lock held by the exiting thread. Neither thread can progress.

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

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