RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

Pavel Rappo prappo at openjdk.org
Wed May 22 18:38:27 UTC 2024


On Wed, 22 May 2024 17:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Pavel,
> 
> > If I read [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown) correctly, due to the mechanics of JVM exit, we simply don't know which thread finishes first: a thread that calls `readPassword` or the shutdown hook.
> 
> IIUC, the thread that waits on `readPassword()` is not a shutdown hook, right? Then I think it is guaranteed that it is still waiting when all the shutdown hooks are executed.
> 
> > If the shutdown hook finishes first, then a `readPassword` thread can corrupt the state: unlike the shutdown hook, which JVM _normally has to wait to complete_, the `readPassword` thread can be terminated at any moment. It might as well be terminated before `finally` but after `echo(false)`, in which case we end up with echo turned off.
> 
> After the shutdown hooks finish, then the VM is terminated (https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#termination). In there:
> 
> ```
> finally clauses are not executed;
> ```
> 
> So I think the shutdown hook's restoreEcho has the final say, sans the situation if some app installs a shutdown hook with `readPassword` but I don't think we can guarantee that case, and I believe it is OK.

I might be confused, but what if the shutdown hook completes and then some application thread enters `readPassword`. If that thread manages to turn off echo before all other shutdown hooks complete, it might never execute `finally`, hence a race.

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

PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125497081


More information about the core-libs-dev mailing list