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 :  
JDK-8059036 - Implement Diagnostic Commands for heap and finalizerinfo
Blocks :  
JDK-8155091 - Remove SA related functions from tmtools
Blocks :  
JDK-8059038 - Create new launcher for SA tools
Relates :  
JDK-7160774 - jinfo, jmap, jstack man pages should document ptrace restrictions in recent Ubuntu versions
Relates :  
JDK-8067194 - Restructure hotspot/agent/src to conform the modular source layout
Relates :  
JDK-7050524 - SA, jinfo, jmap, jstack don't work on Ubuntu > 10.10: DebuggerException: Can't attach to the process
Relates :  
JDK-8151378 - Make the dependency from jdk.jcmd to jdk.hotspot.agent platform dependent
Relates :  
JDK-8043764 - JEP 228: Add More Diagnostic Commands
Description
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.
Comments
I think we can just close this issue as the service dependence is being removed via JDK-8155091.
09-05-2016
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.
22-04-2016
jake changeset: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2d8674642fe
21-04-2016
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); }
08-03-2016
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?
04-03-2016
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).
08-06-2015
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?
05-06-2015