Self-attach using attach API

[Alan Bateman]

The Attach API is maintained on the serviceability-dev list. That would 
the best place to discuss improving the exception message.

The AttachNotSupportedException is intended to be thrown when there 
isn't an attach provider deployed that is compatible with the target VM. 
I don't know anything about the J9 VM to know if the HotSpot provider 
can attach to a J9 VM and vice versa but one could see this exception 
being thrown when a tool running on an OpenJDK build tries to attach to 
a J9 VM. So your point #2 is trying to change the semantics of the 
exception and so needs a bit more thought to see if it make sense or not.

-Alan

On 08/05/2018 10:31, Andrew Johnson wrote:
> I have read through previous discussions about self-attach using the
> attach API.
>
> With JDK 10 I see the following exception on self-attach:
>
> java.io.IOException: Can not attach to current VM
>          at
> jdk.attach/sun.tools.attach.HotSpotVirtualMachine.<init>(HotSpotVirtualMachine.java:75)
>          at
> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:48)
>          at
> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:69)
>          at
> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>          at
> org.eclipse.mat.ibmvm.acquire.IBMDumpProvider$VirtualMachine.call(IBMDumpProvider.java:422)
>          at
> org.eclipse.mat.ibmvm.acquire.IBMDumpProvider$VirtualMachine.attach(IBMDumpProvider.java:542)
>          at
> org.eclipse.mat.ibmvm.acquire.IBMDumpProvider.acquireDump(IBMDumpProvider.java:922)
>          at
> org.eclipse.mat.ibmvm.acquire.IBMDumpProvider.acquireDump(IBMDumpProvider.java:916)
>          at
> org.eclipse.mat.ui.internal.acquire.AcquireSnapshotAction$AcquireDumpOperation.triggerHeapDump(AcquireSnapshotAction.java:310)
>          at
> org.eclipse.mat.ui.internal.acquire.AcquireSnapshotAction$AcquireDumpOperation.doOperation(AcquireSnapshotAction.java:294)
>          at
> org.eclipse.mat.ui.internal.acquire.AcquireSnapshotAction$AcquireDumpOperation.run(AcquireSnapshotAction.java:417)
>          at
> org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
>
>  From the discussion, this is to be expected.
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8180425
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012040.html
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/011943.html
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012201.html
>
> However:
>
> 1. Instead of ' Can not attach to current VM' the message should be '
> Cannot attach to current VM' (Cannot is one word)
> https://en.oxforddictionaries.com/definition/cannot
> 2. Really, the exception should be AttachNotSupportedException, not
> IOException. To me, IOException means that if something was changed this
> call might work. AttachNotSupportedException means 'do not bother
> retrying'. The argument against the change might be that the target
> process does support attach, but just not from the source VM, but the
> documentation seems to allow my suggested change. See the following (with
> typo 'comptatible' ).
> https://docs.oracle.com/javase/10/docs/api/com/sun/tools/attach/AttachNotSupportedException.html
> "Thrown by VirtualMachine.attach when attempting to attach to a Java
> virtual machine for which a compatible AttachProvider does not exist. It
> is also thrown by AttachProvider.attachVirtualMachine if the provider
> attempts to attach to a Java virtual machine with which it not
> comptatible."
> 3. Should attach be allowed, to permit getSystemProperties and
> getAgentProperties but loadAgent() and loadAgentLibrary() (and
> startLocalManagementAgent() etc.) be prohibited?
>
>
> The attach API use case for Eclipse Memory Analyzer is generating heap
> dumps on other running processes on the local machine, then opening them
> and analysing them.
>
> Alternative mechanisms offered by Eclipse Memory Analyzer:
> 1. Running jps / jmap (JDK documentation says these tools are unsupported
> and experimental).
> 2. Using com.sun.tools.attach (and com.ibm.tools.attach for older IBM VMs)
> to list VM processes. If the com.sun.tools.attach classes are not
> available as tools.jar not on classpath, load them via a URLClassLoader.
> Memory Analyzer runs using standard Eclipse OSGi bundles, but this works.
> When acquiring a dump use a small dynamically built jar which is loaded
> into the target process using VirtualMachine.loadAgent(), and generates a
> dump by on IBM VMs calling com.ibm.jvm.Dump.SystemDump() and on OpenJDK
> based VMs using the MBean "com.sun.management:type=HotSpotDiagnostic".
> 3. Start a helper JVM to do the steps of 2. if the current VM is
> unsuitable.
>
> Perhaps Eclipse Memory Analyzer could use JMX, but that is more code to
> write and the old ways used to work.
> The prohibition on self-attach is slightly inconvenient for self-analyzing
> Memory Analyzer (and for some automated tests), but option 3 is a
> work-around.
>
>
> Andrew Johnson
> (Not writing on behalf of IBM, but with interest as committer on Eclipse
> Memory Analyzer http://www.eclipse.org/mat )
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>