DumpJFR tool
Yasumasa Suenaga
suenaga at oss.nttdata.com
Thu Oct 24 14:52:58 UTC 2019
On 2019/10/24 22:50, Erik Gahlin wrote:
> Hi Yasumasa,
>
> The DumpJFR tool relied on SA, which was too much of a burden to maintain (slowing down the development of new JFR features).
>
> I think tool was removed in Oracle JDK 9, at least it was completely broken at that time.
>
> Functionality has been added that allows JFR to dump an emergency dump if the JVM crashes. This reduces the need for a separate tool.
SA is powerful tool for hung up and for postmortem analysis.
For example, SA is only way to gather any information even if Attach Listener does not respond.
JFR emergency dump is not enough.
I commented in JDK-8213435, crash which is caused by -XX:+CrashOnOutOfMemoryError does not contain
recently old object sampling.
In addition, there are some cases not to be called crash handler (e.g. native stack overflow).
> The Event Streaming JEP, targeted for JDK 14, should also help out here, as it ensures the latest file in the disk repository, previously known as the .part file, can always read. With a default flush interval of 1 second, data will be available very close to the point of the crash.
Is flight record flushed to the disk without any programming for Event Streaming?
I guess it is just about Event Stream API.
I hope to get flight record with some configuration - not any programming.
Thanks,
Yasumasa
> Best regards,
> Erik
>
>> Hi all,
>>
>> DumpJFR tool is introduced in JDK 8u60 [1], however it is not available on OpenJDK (JDK 11 or later).
>> Why it is not open sourced?
>>
>> I think DumpJFR is very useful not only for postmortem analysis but also analyzing process hung up.
>> If DumpJFR is available on OpenJDK, I believe JFR will be more useful for troubleshooting.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://www.oracle.com/technetwork/java/javase/8u60-relnotes-2620227.html
>
More information about the serviceability-dev
mailing list