RFR: 8344671: Few JFR streaming tests fail with application not alive error on MacOS 15

[Jaikiran Pai]

On Mon, 17 Mar 2025 18:26:57 GMT, Larry Cable <duke at openjdk.org> wrote:

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 157:

> 155:             snprintf(msg, sizeof(msg), "pid: %d, state is not ready to participate in attach handshake!", (int)pid);
> 156: 
> 157:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException", msg);

I am not too familiar with JNI. Would it be cleaner/beneficial if this native method just returned `JNI_TRUE`/`JNI_FALSE` to indicate whether or not the `SIGQUIT` was sent and then in the Java code side, handle the `throwIfNotReady` part and create and throw the exception if this function returned `JNI_FALSE` and `throwIfNotReady` was `true`?
Would there be any benefit of doing that in the Java side instead of here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2015747468