RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

[Thomas Stuefe]

On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java;
>> The problem was described in [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) with a first try of a fix.
>> A second fix via [JDK-8310191](https://bugs.openjdk.org/browse/JDK-8310191) was necessary.
>> Both fixes just disable the specific subtest on AIX, without correction of the root cause.
>> The root cause is, that dlopen() on AIX returns different handles every time, even if you load a library twice. There is no official AIX API available to get this information on a different way.
>> My proposal is, to use the stat64x API with the fields st_device and st_inode. After a dlopen() the stat64x() API is called additionally to get this information which is then stored parallel to the library handle in the jvmtiAgent. For AIX we then can compare these values instead of the library handle and get the same functionality as on linux.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adopt types

This now causes problems with 

https://github.com/openjdk/jdk/pull/16604#issuecomment-1827661214

since it removes the possibility of silently alternating the file path inside os::dll_load, which would be the preferred way for AIX to handle *.a shared objects. So this causes even more ifdef AIX to bloom up everywhere.

A much better solution would have been to mimic stable-handle behavior inside the AIX version of `os::dll_load`. 

Proposal for an alternate solution: Hold dlhandle-to-(inode, devid)tuple mappings in a hash table. On dlopen, look up dl-handle by (inode, filename) tupel. On dlclose, remove entry. Could have been done inside os_aix.cpp without any changes to shared coding, and would have provided complete coverage for all users of dll_load.

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

PR Comment: https://git.openjdk.org/jdk/pull/15583#issuecomment-1827826924