RFR: 8271949: dumppath in -XX:FlightRecorderOptions does not affect [v4]
Yasumasa Suenaga
ysuenaga at openjdk.java.net
Tue Sep 14 12:23:03 UTC 2021
On Tue, 14 Sep 2021 10:11:04 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
> "I guess you mentioned to the description in JfrConfigureFlightRecorderDCmd::_dump_path. As you know it is one-liner help message, so I think it is prefer to simple. In addition, I don't change semantics of dumppath (and don't change this description)."
>
> I do think the semantics have changed. From invariantly writing the emergency dump to the $PWD, to instead attempting to do it at a user-provided location, which comes with a new set of challenges.
I believe `dumppath` is for specifying the path to dump - @egahlin says so too in PR #4724 . In that context, this PR provides expected behavior in originally.
> "I cannot understand it well, but I guess you pointed "current directory" might be change since startup (start recording). But the same problem exists in current implementation because emergency dump path would be created by os::get_current_directory(), and it will be called when emergency dump happens."
>
> I do not understand this comment. My point about a mismatch is that options "repository" and "dumppath" behave differently when you specify a relative path. "repository" starts out from the $PWD, "dumppath" does not.
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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5019
More information about the hotspot-jfr-dev
mailing list