RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v4]

[Yasumasa Suenaga]

On Tue, 14 Sep 2021 15:13:09 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Set absolute path to JFR emergency dump path
>>  - Check write permission on JFR emergency dump path in configuration
>
> "No, the user can set dumppath with a relative path from $PWD.
> You can see it in the change of jfrEmergencyDump.cpp . get_dump_directory() would build dump path without any other paths when the path is not specified.
> In addition, I changed Options::DEFAULT_DUMP_PATH to . in this PR, then it works fine. It is the evidence that JFR can handle relative path for dumppath rightly."
> 
> Ok, you fixed it in the incremental changeset 'Set absolute path to JFR emergency dump path' - that's good.
> 
> I still see the modified output in the default case, i.e. when no dumppath is specified:
> <pre>
> # CreateCoredumpOnCrash turned off, no core file dumped
> #
> # JFR recording file will be written. Location: D:\temp\SPECjbb2005\SPECjbb2005.\hs_err_pid28564.jfr <<-- note the dot
> </pre>
> "Check write permission on JFR emergency dump path in configuration" introduced an IllegalArgumentException if the dumppath= is invalid for some reason. This will lead to the JVM not starting:
> 
> [19.350s][error][jfr,startup] Cannot write JFR emergency dump to bad_location
> java.lang.IllegalArgumentException: Cannot write JFR emergency dump to bad_location
> Error occurred during initialization of VM
> Failure when starting JFR on_create_vm_2
> 
> This can cause problems for users that pinpoint a location on a mounted drive, in case the mount is not reachable, perhaps because of a temporary network issue. In that case, their entire fleet of JVMs will not start. This might be too strong considering this is an option specifying what to do in an exceptional situation.

@mgronlun Thanks for the comment!
I fixed path resolution, and print warning message instead of throwing exception in new commit. Could you review again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5019