JFR emergency dump didn't happen at OOM
Yasumasa Suenaga
suenaga at oss.nttdata.com
Fri Jul 25 00:53:52 UTC 2025
Hi Erik,
I filed this to JBS, and I've sent PR:
https://github.com/openjdk/jdk/pull/26468
I hope this issue will be fixed soon :)
Thanks,
Yasumasa
On 2025/07/25 2:45, Erik Gahlin wrote:
> Hi Yasumasa,
>
> This looks more reasonable, although most of it is a refactoring.
>
> Could you turn it into a PR with a webrev so it's easier to review?
>
> Thanks
> Erik
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
> *Sent:* Thursday, July 24, 2025 11:21 AM
> *To:* hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
> *Subject:* JFR emergency dump didn't happen at OOM
> Hi all,
>
> I reported and proposed the fix about 6 years ago (!), I faced the issue again that would be helpful if this is fixed.
>
> 6 years ago, we discussed about this issue in [1], then I hear JDK-8196050 might fix this issue, but it hasn't yet happened unfortunately...
>
> JDK codebase has been made a lot of changes in 6 years, so I think we can fix simply than I proposed before.
> All of changes is [2]. It is not so big change and it is good because no flags are added in .jfc files. What do you think? I will send PR if it is ok, but I want to hear your opinions before PR (because we discussed before).
>
> For example, we can pass a flag for OOM rather than exception handler as following:
>
> ```
> --- a/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> +++ b/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> @@ -556,22 +556,21 @@ class JavaThreadInVMAndNative : public StackObj {
> }
> };
>
> -static void post_events(bool exception_handler, Thread* thread) {
> - if (exception_handler) {
> +static void post_events(bool is_oom, Thread* thread) {
> + if (is_oom) {
> + LeakProfiler::emit_events(max_jlong, false, false);
> + } else {
> EventShutdown e;
> e.set_reason("VM Error");
> e.commit();
> - } else {
> - // OOM
> - LeakProfiler::emit_events(max_jlong, false, false);
> }
> EventDumpReason event;
> - event.set_reason(exception_handler ? "Crash" : "Out of Memory");
> + event.set_reason(is_oom ? "Out of Memory" : "Crash");
> event.set_recordingId(-1);
> event.commit();
> }
> ```
>
> And also we can identify whether OOM or not (crash) via `id` in argument of `report_and_die`:
> ```
> --- a/src/hotspot/share/utilities/vmError.cpp
> +++ b/src/hotspot/share/utilities/vmError.cpp
> @@ -1856,7 +1856,7 @@ void VMError::report_and_die(int id, const char* message, const char* detail_fmt
> log.set_fd(-1);
> }
>
> - JFR_ONLY(Jfr::on_vm_shutdown(true);)
> + JFR_ONLY(Jfr::on_vm_shutdown(static_cast<VMErrorType>(_id) == OOM_JAVA_HEAP_FATAL);)
>
> ```
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/2019-January/000381.html>
> [2] https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0 <https://github.com/YaSuenag/jdk/commit/3f18fd74679387c385a8f79c8bea5b6b1f2815c0>
More information about the hotspot-jfr-dev
mailing list