RFR: JDK-8292351: tty should always live
Thomas Stuefe
stuefe at openjdk.org
Tue Aug 16 07:38:35 UTC 2022
On Mon, 15 Aug 2022 22:28:30 GMT, David Holmes <dholmes at openjdk.org> wrote:
> > The goal should be to replace tty with UL
>
> UL has the same problems. UL is configured by argument parsing, so prior to that you can't log. And at some point UL is shutdown, and after that you can't log either.
UL has even more problems. You also cannot use it in signal handlers, and not in subsystems that UL itself uses unless you are really sure you know what you do. For instance, anything below os::malloc cannot use UL (including NMT).
In my eyes, UL is a bit too complex and uses too much VM infrastructure for it to be a use-everywhere logging system. If you use it, you have to think if it is okay. And if people want to expand it, you have to take a lot of care in PR discussions (remember the "lets trace over network" ideas).
I would love to have some sort of automatic mechanism for locally forbidding UL use. Similar to a NoHandleMark. Like a NoULMark. That way we could at least guard code sections that should not use UL, or that UL should not use.
If it were only the argument parsing problem, if UL had no dependencies into the rest of the VM, we could solve that by finding an alternate way to pass logging arguments. E.g. via environment variables. But you would have to move UL initialization up the initialization order, possibly into the C++ dynamic initialization phase, and I'm sure that would not work.
>
> There is no nice solution for the initialization problem. But for termination it should be possible to defer the tty/stream cleanup to an even later point (similarly for UL).
I agree with that. I did not pursue this for tty in this patch since I did not want to make the patch more complex than it is, and easily down-portable.
One problem with UL is that it relies, I believe, on VM infrastructure. At least os::malloc and Thread::current, last time I looked. Not sure if it has more dependencies now. Prolonging UL life may therefore more difficult than just removing it from cleanup.
-------------
PR: https://git.openjdk.org/jdk/pull/9874
More information about the hotspot-dev
mailing list