RFR: 8373439: Deadlock between flight recorder & VMDeath

Erik Gahlin egahlin at openjdk.org
Mon Dec 15 10:55:34 UTC 2025


On Mon, 15 Dec 2025 10:20:34 GMT, Bara' Hasheesh <duke at openjdk.org> wrote:

>> A user may call recording.start() at any time, and throwing an ISE would break the current API and require callers to guard against shutdown. This would affect not just the Recording class but also RecordingStream and FlightRecorder, and possibly the FlightRecorderMXBean. Another alternative is to add PlatformRecorder.isInShutdown checks in various places (stop, dump etc) to make it a dummy recording, but that becomes complicated. An internal checked exception could help ensure all paths are covered. A third alternative is to avoid destroying native JFR at shutdown. That said, we still need to clean up the disk repository. Markus will be back in January. I think we should wait until he returns to get more input on this.
>
>> A third alternative is to avoid destroying native JFR at shutdown 
> 
> I think for this option it's better to wait on Markus as you mentioned
> 
> -------
> 
> For the other options, I don't like the first option of `isInShutdown` as some APIs, are designed to run fine after the flag is set, such as the `stop` API
> 
> As for the internal checked exception, the exception by it self won't be sufficient, as the recoding also needs to be transformed into a "dummy recording" as from a user perspective the application continued normally so the recording "started", otherwise this recording becomes a deadlock hazard 
> 
> Now the aspect of a "dummy recording" is interesting, what do you think about adding a new `RecordingState`  we call it dummy, which we add checks for where is needed within the various APIs

I thought about it, but it doesn't solve the underlying problem and may break things for API users. We might as well use RUNNING and some internal flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28767#discussion_r2618923020


More information about the hotspot-jfr-dev mailing list