JDK 9 introduced the concept of an emergency recording / dump that happens when the JVM crashes or runs out of memory.
The dump file is meant to be the equivalent of hs_err_pid.log file. By default the dump file is called hs_err_pid.jfr and written where the Java process started, but -XX:FlightRecorderOption=dumppath allows a user to override that behaviour and set it to a user-defined path. Very few users are interested in this option.
There are however two problems:
1) The name of the option is misleading. Users may think they should set -XX:FlightRecorder=dumppath to where they want their ordinary recording to be dumped. This is very unfortunate and we should therefore not document the option for JDK 9/10.
2) There is already a flag called -XX:ErrorFile which allows a user to set the path of the hs_err_pid.log file [1] and it would be much better if the hd_err_pid.jfr file is written next to that file. It will simplify the work for support since they can ask customers to send everything that starts with hs_err* to them,
An alternative approach would be to write the dump file where the user have requested their recording file to be. If the user specified -XX:StartFlightRecording=filename=x we would write the file where x points, From a user point of view, this aligns best with the principle of least astonishment. The user don't care if the dump was caused by a crash or normal operation. It would require us to write the filename today kept in Java into a native data structure, so we can access it during a crash. To do this properly, native would also need to know how much to write (which is controlled by maxage and maxsize today). To complicate things further, a user may start a recording without a filename and it's not clear where we should write the file in those cases. Of course, it could be written next to the hs_err_pid.log file, but then there would be mixed behaviours, but it may be OK. There is also the option -XX:StartrFlightRecording=dumponexit that a user can set if they want a recording to be written when the JVM exits. By default that option is false (nothing is written), We would probably need to change that behaviour so a crash dump is always written unless the user explicitly specified dumponexit=false. It should also be noted that we can't guarantee that a valid recording is created during a crash.
Input on this is very much welcomed.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/felog001.html
The dump file is meant to be the equivalent of hs_err_pid.log file. By default the dump file is called hs_err_pid.jfr and written where the Java process started, but -XX:FlightRecorderOption=dumppath allows a user to override that behaviour and set it to a user-defined path. Very few users are interested in this option.
There are however two problems:
1) The name of the option is misleading. Users may think they should set -XX:FlightRecorder=dumppath to where they want their ordinary recording to be dumped. This is very unfortunate and we should therefore not document the option for JDK 9/10.
2) There is already a flag called -XX:ErrorFile which allows a user to set the path of the hs_err_pid.log file [1] and it would be much better if the hd_err_pid.jfr file is written next to that file. It will simplify the work for support since they can ask customers to send everything that starts with hs_err* to them,
An alternative approach would be to write the dump file where the user have requested their recording file to be. If the user specified -XX:StartFlightRecording=filename=x we would write the file where x points, From a user point of view, this aligns best with the principle of least astonishment. The user don't care if the dump was caused by a crash or normal operation. It would require us to write the filename today kept in Java into a native data structure, so we can access it during a crash. To do this properly, native would also need to know how much to write (which is controlled by maxage and maxsize today). To complicate things further, a user may start a recording without a filename and it's not clear where we should write the file in those cases. Of course, it could be written next to the hs_err_pid.log file, but then there would be mixed behaviours, but it may be OK. There is also the option -XX:StartrFlightRecording=dumponexit that a user can set if they want a recording to be written when the JVM exits. By default that option is false (nothing is written), We would probably need to change that behaviour so a crash dump is always written unless the user explicitly specified dumponexit=false. It should also be noted that we can't guarantee that a valid recording is created during a crash.
Input on this is very much welcomed.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/felog001.html
- duplicates
-
JDK-8213435 Dump JFR recording on ExitOnOutOfMemoryError
-
- Closed
-
- relates to
-
JDK-8364090 Dump JFR recording on CrashOnOutOfMemoryError
-
- Resolved
-