JDK-8059035 : Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2014-09-24
  • Updated: 2016-08-02
  • Resolved: 2016-05-10
Related Reports
Blocks :  
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Some of the options in jstack, jinfo and jmap tools will invoke methods in the Serviceability Agent (which is in jdk.hotspot.agent) through reflection. This will not work in a modularized world.

We should remove these options from the tools.
I think we can just close this issue as the service dependence is being removed via JDK-8155091.

jdk.jcmd no longer has the dependency on jdk.hotspot.agent. Instead it finds it through service provider. We can drop "m4" label since any remaining work is independent to the module system.

jake changeset: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2d8674642fe

One possible quick-and-dirty service interface for M3 (and modify it post-M3 if desirable) something like this: abstract class AgentToolProvider { void run(String name, String... arguments); } sun.tools.jstack.JStack will call ServiceLoader.load(Layer.boot(), AgentToolProvider.class) and if a provider is present, AgentToolProvider::run("jstack", arguments). jdk.hotspot.agent will provide an implementation of AgentToolProvider to support a list of well-defined names for supporting jstack. jinfo, jmap. Another alternative is to have one provider for each SA tool entry pont. abstract class AgentToolProvider { String getName(): void run(String... arguments); }

This is an unfortunate dependency, which will break the build on every platform (e.g. AIX) which doesn't have SA. Any idea when this issue will be addressed?

SA will continue to need whatever permissions are required by the OS to do ptrace. But the j* commands will not use SA, instead they use the attach framework (which is a co-operative way for the two processes to communicate, requiring no special privileges).

Just to confirm, we expect this to fix the problem in JDK-7050524, which was earlier closed as infeasible. Or perhaps SA will continue to be "broken" while the "j" commands will be fixed?