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
