On Wed, 6 Sep 2023 08:18:45 GMT, JoKern65 <d...@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.

I would much rather see an AIX solution that was in the AIX version of 
`os::dll_load` rather than having to pollute the shared JVMTI code. I'm not 
sure how best to achieve that - it may not be possible to hide it completely - 
but we should be able to refactor things so `stat64x_LIBPATH` is defined in AIX 
code, and its use is via a helper so the code is only written once. Then we 
would only need a handful of `AIX_ONLY(...)` statements.

src/hotspot/share/prims/jvmtiAgentList.cpp line 251:

> 249:   while (it.has_next()) {
> 250:     JvmtiAgent* const agent = it.next();
> 251:     if (!agent->is_static_lib() && device && inode &&

Style nit: we don't use implicit booleans so check `device != 0` and  `inode != 
0` explicitly please.

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

PR Comment: https://git.openjdk.org/jdk/pull/15583#issuecomment-1714969165
PR Review Comment: https://git.openjdk.org/jdk/pull/15583#discussion_r1322387181

Reply via email to