Regarding options of error and dump file paths

[sakatakui]

Hi Thomas,

Thank you for your comment.

> Would it not be way less complex to just set the current working
> directory to wherever you want to direct the output?

I see your point, but setting an output directory with the option is 
handier than changing the current working directory. Changing it 
sometimes makes a mistake.
Also, the working directory is unchangeable in container environment 
when build instructions like Dockerfile already set another directory to 
the working directory and the directory has some sort of meaning.

> We even could give the VM a new option to let it cwd into a specific
> directory after launching.

I appreciate your input. Do you mean that we will be able to change the 
working directory through an existing command with the new option if we 
add it?

Regards,
Koichi

On 23-08-2021 01:54 PM, Thomas Stüfe wrote:
> Hi Koichi,
> 
> Would it not be way less complex to just set the current working
> directory to wherever you want to direct the output?
> 
> We even could give the VM a new option to let it cwd into a specific
> directory after launching.
> 
> Cheers, Thomas
> 
> On Mon, Aug 23, 2021 at 5:29 AM Koichi Sakata
> <sakatakui at oss.nttdata.com> 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.
>> 
>> Regards,
>> Koichi