RFR: 8371944: AOT configuration is corrupted when app closes System.out
Igor Veresov
iveresov at openjdk.org
Wed Nov 19 18:09:30 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.
Marked as reviewed by iveresov (Reviewer).
Marked as reviewed by iveresov (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3484055038
PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3484057678
More information about the hotspot-runtime-dev
mailing list