RFR: 8373439: Deadlock between flight recorder & VMDeath [v2]

[Bara' Hasheesh]

On Wed, 21 Jan 2026 14:06:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> There are also behavioral questions, e.g. what should happen if a user calls Recording::dump on a dummy?

Yes, which is why I initially went with an exception as it's much clearer in terms of behaviour 

> Throwing an exception creates a burden for users of the API.
>
> We will need to think some more on how to fix this.

As you're aware JFR backend/components are cleaned up during the shutdown hook via a call to `recorder.destroy()`, as such trying to do any JFR work after that, doesn't make much sense

I can't really think of a way to make JFR "work" without keeping JFR components alive during a JVM death which will create it's own problems (when will these resources be eventually cleared?)

**IMO the first thing we should do is to define what the behaviour should be, after that we can investigate/discuss on how that can be done/achieved**


For throwing an exception, the current documentation is the following


  /**
     * Starts this recording.
     * <p>
     * It's recommended that the recording options and event settings are configured
     * before calling this method. The benefits of doing so are a more consistent
     * state when analyzing the recorded data, and improved performance because the
     * configuration can be applied atomically.
     * <p>
     * After a successful invocation of this method, this recording is in the
     * {@code RUNNING} state.
     *
     * @throws IllegalStateException if recording is already started or is in the
     *         {@code CLOSED} state
     */


This documentation does not make any guarantees that the call will be successful, so I can see some freedom in defining some new errors here

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

PR Comment: https://git.openjdk.org/jdk/pull/28767#issuecomment-3778890869