RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v4]

[Michael McMahon]

On Mon, 12 May 2025 11:26:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `ServerUdsChannelHolder` is introduced to manage the life cycle of a `ServerSocketChannel` created using Unix domain sockets (UDS) in a thread-safe manner.
>> 
>> ### Testing
>> 
>> Changes can be tested as follows:
>> 
>> 
>> make build-microbenchmark
>> build/linux-x64/jdk/bin/java \
>>   -jar build/linux-x64/images/test/micro/benchmarks.jar \
>>   -f 1 -wi 1 -i 1 -t 2 \
>>   "(SocketChannelConnectionSetup|UnixSocketChannelReadWrite)"
>> 
>> 
>> ### Background
>> 
>> A UDS need to be pointed to a _non-existent_ file, which is to be created by `bind()`. The created file needs to be deleted as a part of the clean-up at exit. When tests employing UDS run in parallel, failures can happen at multiple places:
>> 
>> - `bind()` can fail, if the file is already created by another thread
>> - the clean-up of the socket file can fail, if the file is already deleted
>>   - reported for `SocketChannelConnectionSetup` in [8350915](https://bugs.openjdk.org/browse/JDK-8350915)
>>   - reported for `UnixSocketChannelReadWrite` in [8351601](https://bugs.openjdk.org/browse/JDK-8351601)
>> - the clean-up of the socket file parent directory can fail, if not all threads deleted their socket files, and hence, the folder is not empty
>>   - reported for in `SocketChannelConnectionSetup` in [8354024](https://bugs.openjdk.org/browse/JDK-8354024)
>> 
>> This PR introduces `ServerUdsChannelHolder` utility to manage the life cycle of a UDS and avoids above shared issues by:
>> - using a dedicated (temporary and unique) parent folder for the socket
>> - encapsulating the termination logic (i.e., closing the socket, deleting the socket file and its (dedicated) parent folder) in `AutoCloseable::close`
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve UDS file path obtain

test/micro/org/openjdk/bench/java/net/SocketChannelConnectionSetup.java line 58:

> 56: 
> 57:     @Param({"INET", "UNIX"})
> 58:     private volatile String family;

This version looks a lot simpler, which is good. This question applies regardless of your change but I'm wondering why the field `family` is volatile but the other fields such as `sscFilePath` are not? I guess if we are sure that the JMH configuration guarantees that the setup, teardown and test methods are all run by the same thread, then they don't need to be volatile. But, I'm not sure if that is the case..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24568#discussion_r2084934999