JDK-8244190 : JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11.0.7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2020-04-23
  • Updated: 2021-04-22
  • Resolved: 2021-04-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17 b19Fixed
Description
ADDITIONAL SYSTEM INFORMATION :
Applies to all operating systems.

A DESCRIPTION OF THE PROBLEM :
When a JVM is started with the -XX:StartFlightRecorder option, output is written to stdout indicating either success or failure that the recording is started. This breaks scripts that use Java in an interactive way to parse data, since the output message is in a non-structured form and does not match the format expected.

For example, if a Java command is being used to base64 encode an input file, and write encoded output to stdout, then it cannot be profiled with JFR in situ since the output will then no longer be correct base64 encoded output. As the goal of JFR is to allow a low-latency profiling solution that can be enabled in production, any such command whose stdout is important cannot be used in this way.

Providing a workaround option in the JFR.start DCmdStart to ignore output or have it routed elsewhere would be a way of disabling it, but a longer term option might be to use unified logging to display the message instead of stdout.
Comments
Changeset: 7c37c022 Author: Erik Gahlin <egahlin@openjdk.org> Date: 2021-04-16 17:26:13 +0000 URL: https://git.openjdk.java.net/jdk/commit/7c37c022
16-04-2021
That's a good suggestion. I will look into it.
30-07-2020
How about you mark the output for jfr+startup info logging and have StartFlightRecording enable that logging level if not explicitly disabled? That way the output is the same, no other output is affected and the user can still turn it off if needed. I'm just not sure we have a way to query if the logging level has been explicitly set to a given value.
30-07-2020
We have been aware of this problem for some time, but we haven't been able to settle on the approach to fix it. Here are some solutions we are considering. 1) Disable output by default and enable it using a unified logging tag: -Xlog:jfr+startup -XX:StartFlightRecording 2) Add an option to silence the output: -XX:StartFlightRecording:quiet=true We have thought about enable unified logging tag by default, and then the user can disable it, i.e -Xlog:jfr+startup=off, but it would change the initial configuration, which could impact other things. Benefit of 1 is that it is consistent with other logging, but user may think JFR is no longer working when they don't see the output. They also don't know the PID or how to dump easily. Few will think of using -Xlog:jfr+startup Benefit of 2 is that it solves the problem, but keep current behaviour. Users will not think JFR is not working anymore. It is also possible to backport this approach without causing confusion.
29-07-2020
Moving across to development team for evaluation.
30-04-2020