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

[Larry Cable]

On Thu, 27 Mar 2025 06:27:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> 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?

it would be different not necessarily better and this is the same pattern as is used for the pre-existing Linux imp

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

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