Regarding options of error and dump file paths

[David Holmes]

Hi Koichi,

On 23/08/2021 1:29 pm, Koichi Sakata wrote:
> Hi all,
> 
> I'm writing to get feedback on my idea about options for error and dump 
> file paths.
> 
> First of all, we can specify several options related to error and dump 
> files. For example, the HeapDumpPath option sets the heap dump file and 
> the ErrorFile option sets the hs_error file.
> 
> I've felt inconvenience about that because we need to write all path 
> options to put those files in a specific directory. I also recognize 
> that they are outputted in the working directory when I run an 
> application with no options. But I'd like to keep them in any directory. 
> So the new option that sets the directory where those files are 
> outputted would be useful, I think.
> 
> The new option helps us especially to run applications on containers 
> like Docker, Kubernetes etc. If we run them without those existing 
> options on containers, files will be put in the local directory of each 
> container. We lose files after we operate the container such as deleting 
> it. The option enables us to keep certainly all error and dump files if 
> we just specify the path of the persistent volume for the new option.
> 
> As a concrete example, when we specify -XX:ErrorAndDumpPath=/foo/bar/ 
> (This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and 
> -XX:StartFlightRecording etc., files are generated in the /foo/bar 
> directory. From my point of view, the option will deal with the 
> following files:
> - heap dump file (java_pid%p.hprof)
> - error log file (hs_err_pid%p.log)
> - JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr, 
> hs_soe_pid%p.jfr)
> - replay file (replay_pid%p.log)
> 
> The existing path options should override the new option. If I set 
> -XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a heap 
> dump file will be in the /foo/baz directory and other files will be 
> created in the /foo/bar.
> 
> I would like to hear your point of view. If some people agree to this 
> idea, I will write a patch.

My initial reaction was that this seemed something better handled in a 
launch script because I figured if you had complex needs in relation to 
where these files were being placed, then you'd use a launch script to 
help manage that anyway.

But I can see there would be some convenience to controlling the output 
directory without also having to restate the default file names.

Having an explicit option override the default directory option is a 
good idea, but I'm not sure it is that clear cut. If you can specify a 
relative directory and file name for a given dump file, might you not 
want that to be relative to the specified default path, rather than 
relative to the pwd?

And we actually have quite a lot of potential output files from:
  - GC (heap dumps)
  - JIT (replay files)
  - hs_err files
  - JFR (a number of files)
  - jcmd/dcmd dumps?
  - Unified logging?

I think figuring out the exact details of how this should work, and 
interact with all the different files involved may be more involved than 
just prepending a path component.

I also think I would need to hear much greater demand, with detailed 
usage expectations, before supporting this.

Just my 2c.

Cheers,
David
-----

> Regards,
> Koichi