During testing of my fix for 6964018, I have noticed that sometimes
the jmap program hangs on Cygwin when it is racing with target program
termination. The usual result of a jmap call on a program that has
terminated is:

    <pid>: [Nn]o such process

Cygwin uses "no"; others use "No".

However, there can also be other "failures" from such a late call to jmap:

6964018 INFO: Exception in thread "main" java.io.IOException: The pipe is being closed
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method)
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:100)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.heapHisto(HotSpotVirtualMachine.java:185)
6964018 INFO: at sun.tools.jmap.JMap.histo(JMap.java:219)
6964018 INFO: at sun.tools.jmap.JMap.main(JMap.java:138)
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


6964018 INFO: 6092: Access is denied
6964018 INFO: The -F option can be used when the target process is not responding
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


6964018 INFO: Exception in thread "main" java.io.IOException: Access is denied
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.enqueue(Native Method)
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:96)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.heapHisto(HotSpotVirtualMachine.java:185)
6964018 INFO: at sun.tools.jmap.JMap.histo(JMap.java:219)
6964018 INFO: at sun.tools.jmap.JMap.main(JMap.java:138)
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


6964018 INFO: Exception in thread "main" java.lang.InternalError: Remote thread failed for unknown reason
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.enqueue(Native Method)
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.<init>(WindowsVirtualMachine.java:62)
6964018 INFO: at sun.tools.attach.WindowsAttachProvider.attachVirtualMachine(WindowsAttachProvider.java:69)
6964018 INFO: at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213)
6964018 INFO: at sun.tools.jmap.JMap.attach(JMap.java:296)
6964018 INFO: at sun.tools.jmap.JMap.histo(JMap.java:218)
6964018 INFO: at sun.tools.jmap.JMap.main(JMap.java:138)
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


6964018 INFO: 4208: Not enough storage is available to process this command
6964018 INFO: The -F option can be used when the target process is not responding
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


6964018 INFO: Exception in thread "main" java.io.IOException: Not enough storage is available to process this command
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.enqueue(Native Method)
6964018 INFO: at sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:96)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213)
6964018 INFO: at sun.tools.attach.HotSpotVirtualMachine.heapHisto(HotSpotVirtualMachine.java:185)
6964018 INFO: at sun.tools.jmap.JMap.histo(JMap.java:219)
6964018 INFO: at sun.tools.jmap.JMap.main(JMap.java:138)
6964018 INFO: retrying jmap (1).
6964018 INFO: the previous 1 retries were likely due to races with AnonLoggerWeakRefLeak termination.
6964018 INFO: jmap_retry_cnt = 1


All of the "failures" of jmap due to such a late attach are dealt with
by grouping them with the final "[Nn]o such process" failure mode. Since
we're sampling a target program without direct control, it is the nature
of the beast to deal with process termination races.

However, the jmap hang isn't something that we can easily deal with
in these test programs. I'm filing this bug to track this hang in jmap.
Perhaps jmap can be made more robust in the face of target program
termination.