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

Ryan Ernst duke at openjdk.org
Tue Jul 5 04:51:42 UTC 2022


On Tue, 5 Jul 2022 04:06:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Signal handlers for eg SIGTERM invoke Shutdown.shutdown. That method holds the same lock as Shutdown.exit and runs shutdown hooks. So if a signal handler triggers shutdown, and before the system halts Runtime.exit is invoked, the status passed to Runtime.exit will be ignored.
>
> First, the signal handlers actually invoke Shutdown.exit, not Shutdown.shutdown  - see Terminator.setup(). (If they did the latter, like DestroyJavaVM, then an exit(status) call from another thread could still do the final VM halt(status)
> 
> But now you are opening a can of worms. There are multiple ways for the VM to initiate termination - are you going to try and describe here how all of them potentially interact?  
> 
> What you are really stating here is that other parts of the JDK can invoke System.exit, but that is for them to specify where such things are specified, it isn't for exit() to try and list them all. All we have to do here is describe how multiple calls to exit() behave.

Aha! I think I misread the comment on Shutdown.shutdown and had it stuck in my head that signals would exit through that method. Thanks for the explanation, it makes a lot more sense now.

> All we have to do here is describe how multiple calls to exit() behave.

The thing that is still missing to me is that an application developer may have a single call to System.exit, yet the status code they pass to it may not be the one the jvm exits with.

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

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


More information about the core-libs-dev mailing list