RFR: 8371944: AOT configuration is corrupted when app closes System.out
Vladimir Kozlov
kvn at openjdk.org
Tue Nov 18 05:14:06 UTC 2025
On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
>
>
> try (var err = new PrintWriter(System.err);
> var out = new PrintWriter(System.out)) {
> out.println("Hello Confused World");
> }
>
>
> This has the side effect of closing the JVM's STDOUT.
>
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
>
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
>
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
>
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
>
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.
@iklam thank you for explaining the issue in details. You fix is reusable for me based on this.
-------------
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3475480680
More information about the hotspot-runtime-dev
mailing list