PING: RFR: 8233373: hs_err should report the location of JFR files

[Yasumasa Suenaga]

Hi Markus,

How about this?

   http://cr.openjdk.java.net/~ysuenaga/JDK-8233373/webrev.01/

I do no agree to pass outputStream instance to JFR implementation in HotSpot because we need to consider
'#' and indents.
I think it might be hard to maintain if "#" and indents would be printed in different place.

So I want to add getters for emergency dump path and repository path to Jfr class.


Thanks,

Yasumasa


On 2019/11/29 19:26, Markus Gronlund wrote:
> Hi,
> 
> I have not looked at all the details yet, but from a high level:
> 
> You should try to keep JFR specific logic encapsulated in JFR code as much as possible. jfrRepository.hpp and jfrEmergencyDump.hpp are internal modules, so they should not leak out into vmError.cpp.
> The jfr.hpp is the external interface for the VM to interact directly with JFR. I would hope that there is only one invocation needed in vmError.cpp, something like JFR_ONLY(Jfr::on_error_reporting(outputStream* out);).
> If there are multiple callouts needed to coordinate the layout, then you might need multiple entries in jfr.hpp, but please try to keep them to a minimum.  Pure textual output, such as aligning spaces and # can be printed directly in vmError.cpp of course.
> 
> Thanks
> Markus
> 
> 
> -----Original Message-----
> From: Yasumasa Suenaga <suenaga at oss.nttdata.com>
> Sent: den 19 november 2019 02:32
> To: hotspot-jfr-dev at openjdk.java.net
> Cc: yasuenag at gmail.com
> Subject: PING: RFR: 8233373: hs_err should report the location of JFR files
> 
> PING: Could you review?
> 
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8233373
>>     webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233373/webrev.00/
> 
> 
> Yasumasa
> 
> 
> On 2019/11/01 13:38, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> Please review this change:
>>
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8233373
>>     webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8233373/webrev.00/
>>
>> Since JFR Event Streaming (JEP 349), JFR file in the repository would keep most recently data.
>> It is very useful for postmortem analysis. So it helps JVM engineer to acquire them from the user if hs_err log points it.
>>
>>
>> Examples:
>>
>> * Show JFR repository path:
>> ```
>> # JFR files might be saved in the repository:
>> # /tmp/2019_11_01_11_09_30_3529
>> ```
>>
>> * Show emergency dump path
>> ```
>> # JFR data is saved as:
>> # /home/ysuenaga/github/garakuta/NativeSEGV/hs_err_pid3807.jfr
>> ```
>>
>>
>> This webrev passed all tests on submit repo (mach5-one-ysuenaga-JDK-8233373-20191101-0248-6329106)
>>
>>
>> Thanks,
>>
>> Yasumasa