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
