JDK-8354047 : Avoid printing unwanted warning to stdout for hsperf file issues
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2025-04-08
  • Updated: 2025-05-08
  • Resolved: 2025-05-08
Related Reports
Causes :  
JDK-8286030 - Avoid JVM crash when containers share the same /tmp dir
Description
Prior to JDK-8286030, the JVM could crash if several instances tried to access the same hsperf file at the same time. JDK-8286030 fixed the crash, but added a warning message if a race is detected. Unfortunately, this message is printed to stdout, a problem which is only exaggerated by the fact that it is rare and quite unexpected, so it causes intermittent failures.

This causes problem with the build (see JDK-8327099), but some googling indicates that this is also causing real-world problems for other users as well (see e.g. https://stackoverflow.com/q/79559390, https://github.com/apache/arrow/issues/39113)

At the very least, any error message should be printed to stderr. In general, I think the JVM should be extremely reluctant to print anything at all to stdout or stderr, since it will interfere with the user application running.
Comments
See also the discussion in JDK-8327099. We will not be changing the way warnings are generated in the VM code.
08-05-2025
If this new warning is particularly problematic it may be that it occurs much more frequently than expected - in which case a warning may not be appropriate (though it does indicate a problem with the way things are executing). It can also be redirected with -Xlog:perf+memops=warn:stderr EDIT: This is NOT a new warning it was added in JDK 20. And it arises in a very specific container environment, so it is unclear to me how this affects our build? Perhaps the warning in the build arises from a completely different source? In which case that problem needs investigating.
10-04-2025
VM warnings are on by default and occur for a number of potential reasons. Yes they can disrupt the build but they are there for a reason. And warnings going to stdout is a long standing (and yes somewhat controversial and complex) behaviour for the VM - the default output stream for all logging is stdout. If going to stderr would help the build then I suggest that the build redirect logging to stderr: > - XX:+DisplayVMOutputToStdErr (for non-Unified Logging warnings, though will also impact other things) > -Xlog:all=warn:stderr Changing the default behaviour to alleviate build problems is not feasible.
10-04-2025
Pinging [~iklam] since you were responsible for the original fix in JDK-8286030.
08-04-2025