RFR: JDK-8292351: tty should always live [v4]
Thomas Stuefe
stuefe at openjdk.org
Wed Aug 17 13:53:22 UTC 2022
On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes.
>>
>> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging.
>>
>> tty should always be safe to write to, and that is trivial to do.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>
> Change comment
The problem I have with extending tty's life to beyond VM destruction is that tty is defaultStream and defaultStream is not simple. Just look at defaultStream.write, I find it not easy to decide whether all of this is safe (e.g. using tty_lock) after the VM shut down. Then, you want the destructor of defaultStream to run during VM destruction, since we want the flush.
After VM destruction, I want simple unbuffered IO for any subsequent messages. Keep it simple and stupid.
If you think using stderr is such a problem for *unplanned* tty output, then we could just assign tty either 1 or 2 depending on the arguments that are now, at the end of VM life, available.
-------------
PR: https://git.openjdk.org/jdk/pull/9874
More information about the hotspot-dev
mailing list