RFR: 8353938: hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static JDK

[Jiangli Zhou]

On Tue, 8 Apr 2025 02:25:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
> 
> ```
> JVMTI.agent_load [arguments]
> Loads JVMTI native agent.
>   Impact: Low
> arguments:
>   library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
>   agent option: (Optional) Option string to pass the agent. (STRING, no default value)
> ```
> 
> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see  https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.

I discussed the `JVMTI.agent_load` issue on static support with @AlanBateman this morning as part of the hermetic Java meeting. @AlanBateman suggested considering adding an alternative diagnostic command or argument for the static (built-in) agent load support. We also discussed the use case of statically-linked dynamic (attached) native agents loaded by `jcmd` tool on static, and considerations for resolving (or clarifying) the `JVMTI.agent_load` static support at a later point when usage requirements were more clear. Outside the jtreg tests, I haven't run into any such usages yet. 

Based on the discussion, I'll update this PR to skip the `LoadAgentDcmdTest` on static JDK for now.

I'll file a separate bug for the `JVMTI.agent_load` issue on static support so we can revisit that when things are more clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/24497#issuecomment-2787388528