RFR: 8315004: Runtime.halt() debug logging
Alan Bateman
alanb at openjdk.org
Tue Oct 31 06:56:36 UTC 2023
On Fri, 1 Sep 2023 08:29:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> I think you may have missed the comment in the JBS issue. Logging means running potentially arbitrary code, doing this at Runtime.halt time is problematic. I thought the conclusion from the work on Runtime.exit was not to log in Runtime.halt?
>
>> @AlanBateman Sorry for missing your comment on JBS. I can't find any discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not sure if it was intentional that no logging output was added to Runtime.halt.
>> However, if Runtime.halt is overlooked without discussion, I think it should be added after considering the need.
>> I think it's the same problem as Runtime.exit when it comes to executing arbitrary code.
>> Are there any issues specific to Runtime.halt?
>
> The purpose of the halt method is to terminate immediately, it doesn't initiate the shutdown sequence. My recollection of the System.exit logging is that it was deliberate to not change the halt method. Changing halt to log means it would not terminate immediately. Also I think there were concerns with logging libraries that needed the shutdown hook to execute in order to fush/close logs. @RogerRiggs or @stuart-marks may be able to say more about this.
> @AlanBateman @RogerRiggs Could you comment on the above?
Changing Runtime.halt to log means it would not terminate immediately. It's worse: Logging is pluggable so it means logging can potentially run "faraway" and arbitrary code. We have to super cautious with logging in core classes. The conclusion from the work on Runtime.exit was to not add this logging to Runtime.halt. So I don't think the changes in the PR should be integrated.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1786553171
More information about the core-libs-dev
mailing list