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

Chris Hegarty chegar at openjdk.org
Tue Jul 5 08:07:27 UTC 2022


On Tue, 5 Jul 2022 07:23:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I like the new suggested wording, but I would slightly tweak it. As Alan mentioned in another comment the first paragraph makes clear the method never returns normally. How does the following sound?
>> 
>>> If this method is invoked after shutdown hooks have already been started, the supplied status code will be ignored. If this method is invoked from a shutdown hook the system will deadlock.
>
>> gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals.
> 
> The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too. But discussion of signals has no place here - I'm not even sure we document those ways of terminating the VM anywhere?

@dholmes-ora Agreed - this paragraph should not explicitly mention signals or any _other_ means of termination.  

There is some shutdown hook specific verbiage relating to termination in `Runtime::addShutdownHook` :


In rare circumstances the virtual machine may abort, that is, stop running without shutting
down cleanly. This occurs when the virtual machine is terminated externally, for example
with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The
virtual machine may also abort if a native method goes awry by, for example, corrupting
internal data structures or attempting to access nonexistent memory. If the virtual machine
aborts then no guarantee can be made about whether or not any shutdown hooks will be run.


... but we do not need to go there, and it's not really enough to leverage anyway. 

>The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too.

Exactly. On further reading of the proposed "Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code.", I think that it is fine (given its position and context in Runtime::exit). My reason for suggesting an alternative ("If this method is invoked after shutdown hooks have already been started, it will block indefinitely") was mainly to try to find something a little simpler while retaining correctness.  Given the discussion so far, either is fine with me.

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

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


More information about the core-libs-dev mailing list