RFR: 8275375: [REDO] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect

Yasumasa Suenaga ysuenaga at openjdk.java.net
Tue Oct 19 03:15:48 UTC 2021


On Tue, 19 Oct 2021 02:13:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This PR is for redo-ing [JDK-8271949](https://bugs.openjdk.java.net/browse/JDK-8271949).
> I changed to use `SecuritySupport` at `Options::setDumpPath` as @egahlin mentioned. Please see change both Options.java and SecuritySupport.java .
> 
> I've tested this change with all jdk/jfr tests on Linux x64, and they works fine.
> @egahlin @mgronlun Can you run Mach5 tests with this change?

> There are three ways setDumpPath is used:
> 
> 1. When JFR is initialized
> 2. jcmd JFR.configure dumppath=
> 3. -XX:FllightRecorderOptions:dumppath=
> 
> If something goes wrong (IOException/InvalidPathException) when doing 2 or 3, users should ideally be informed, so they can correct it, at command-line or jcmd. Perhaps throw DCmdException?

Agree, we can use DCmdException if IOE happens. However we need to concider 1 because some processes might be run on "/" with unprivileged user.

> Do we really need to resolve for 1? Can we handle it in native, similar to what we already do with hs_err_pid (which is not resolved in Java). For example, null could be used to indicate that the working directory should be used.

In hs_err log, the path would not resolved, it uses `os::get_current_directory()` at `VMError::prepare_log_file()` when -XX:ErrorFile is not set. For example, we can see following message on the console when we set -XX:ErrorFile=error.log, and error.log is located at current directory.


# An error report file with more information is saved as:
# error.log


I'm not particular path resolution if we can ignore original behavior (resolved dump path will also be shown at UL). We will not have to think about SecurityException if we don't need to resolve dump path at `setDumpPath()`. In addition we can implement it more simple. So I agree with you to be honest that to pass `null`.

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

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


More information about the hotspot-jfr-dev mailing list