3

I'm trying to run and debug the utilies from sun.jvm.hotspot.tools and sun.jvm.hotspot.utilities (like JMap.java) in order to understand better what is going on.

Unfortunately I get stuck very early with the following error message and don't even get to debug a lot: 

Attaching to process ID 5144, please wait...
Error attaching to process: Timed out while attempting to connect to debug server (please start SwDbgSrv.exe)

It seems like for whatever reason the tools are trying to connect to a "debug server" running on port 27000.

In the doc of the sun.jvm.hotspot.tools.HeapDumer.java I found the following:

This tool is used by the JDK jmap utility to dump the heap of the target process/core as a HPROF binary file. It can also be used as a standalone tool if required.

So I (maybe naively) assumed that jmap.exe is somehow using that, but I never had this kind of problems using creating a heap dump using jmap. I never needed to start another process first.

Any ideas what I need to do to run all those tools directly from my dev env?

Thanks

Haasip Satang
  • 457
  • 3
  • 17

1 Answers1

2

sun.jvm.hotspot.* tools are the part of HotSpot Serviceability Agent.

I assume you use JDK 6 on Windows, because the debug server is no longer required since JDK 7. In earlier versions you had to start SwDbgSrv.exe in order to use Serviceability Agent.

Some built-in JDK utilities (jmap, jstack) have two execution modes: cooperative and forced. In normal cooperative mode these tools use Dynamic Attach Mechanism to connect to the target VM. The requested command is then executed directly by the target VM from within the target process.

The forced mode (jmap -F, jstack -F) behaves quite differently. The tool suspends the target process and then reads the process memory using Serviceability Agent. The command is executed in the tool's process while the target VM is paused. This is what sun.jvm.hotspot.* utilities do.

apangin
  • 92,924
  • 10
  • 193
  • 247
  • Interesting answer, didn't know there were changes from JDK 6 to 7. Actually I still don't get it to be honest: 1. I don't have a `SwDbgSrv.exe`, not even in my JDK 6 installation. 2. I'm using the open **JDK 7** sources (`sun.jvm.hotspot.tools.HeapDumper, sun.jvm.hotspot.tools.JMap`. etc) and the tools still require this server to be started (no clue where I can get it). I would like t debug the tools in Eclipse and hence trying to start everyhting there rather than executing jmap on the console (sorry if that wasn't clear from above). Any more ideas? – Haasip Satang Jun 07 '15 at 10:22
  • @HaasipSatang 1. `SwDbgSrv.exe` is not shipped with JDK. 2. You have the outdated sources. Where did you get them? [Here](http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/) are the latest JDK 7 HotSpot sources. 3.You probably don't need these tools at all. As I've told, you can use Dynamic Attach to get a thread dump or heap dump. This is very easy. Look at [JVM Serviceability examples](https://github.com/odnoklassniki/jvm-serviceability-examples), particularly, [demo2](https://github.com/odnoklassniki/jvm-serviceability-examples/blob/master/src/demo2/VmCommand.java). – apangin Jun 07 '15 at 21:56
  • Thanks. I really had a quite old version of the OpenJDK 7 sources. But it was 7, not 6. So something might have changed within 7. So when I started my project with OpenJDK and used the new sources for JMap it now connects and I can debug. I had to create an sa.properties file though and use sun.jvm.hotspot.runtime.VM.disableVersionCheck=true (as I did't know which values to set). So I'm obviously not using it correctly yet, but at least it works for now and I can debug. Just out of curiosity, do you know where I could find the `SwDbgSrv.exe` in case I need it one day? – Haasip Satang Jun 09 '15 at 11:53
  • @HaasipSatang To be more precise, this was changed in 7u2. The only way to get `SwDbgSrv.exe` is probably to build it from [sources](http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/agent/src/os/win32). – apangin Jun 09 '15 at 12:15
  • thanks :) And just FYI: I'm not doing all this to create a heap dump. I'm actually trying to find out how I can get the same object id that is written in the heap dump at runtime from an object.So basically I want to create a heap dump, and at some later point in time get the object id of a live object and compare it with its values from the heap dump. I thought the id was the memory address. But the value I got with sun.misc.Unsafe is different. That's why I wanted to debug those classes to see how they get the id. Do you think I can get it "in process" as well rather than attaching? – Haasip Satang Jun 09 '15 at 17:21
  • Actually I asked this question [here](http://stackoverflow.com/questions/30629014/how-to-get-object-id-as-used-in-heap-dump?noredirect=1#comment49325096_30629014) already before I tried to debug the hotspot classes . As for this question here, it only works with both processes running OpenJDK. Are you aware of a similar solution for Oracle JDK? – Haasip Satang Jun 09 '15 at 17:34
  • @HaasipSatang Object ID in the heap dump is the address of an object at the moment of dumping [(the source)](http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f547ab7c2681/src/share/vm/services/heapDumper.cpp#l564). However, this ID is not persistent since objects may move along the heap. – apangin Jun 10 '15 at 13:43
  • When using Serviceability Agent both client and server should run the same Java version. Oracle JDK is based on OpenJDK, so the solution must be same for Oracle JDK, too. – apangin Jun 10 '15 at 13:46
  • Doh! True, I forgot about that. Objects might move between the different mem spaces :-/ Strange that I never got one case that works though. That could either mean that all the objects I tested with moved spaces or that there was still something wrong with my test. ( I assume the latter one, as at least for classes the address shouldn't change, right? They should stay in perm space (in JDK 7)). – Haasip Satang Jun 10 '15 at 16:12
  • @HaasipSatang Right. How did you get the object address via Unsafe? Maybe the problem is there. – apangin Jun 10 '15 at 16:38
  • I used the appraoch descibed [here](http://zeroturnaround.com/rebellabs/dangerous-code-how-to-be-unsafe-with-java-classes-objects-in-memory/3/) but none of the values I retrieved was similar to what I had in my heap dump (which I created programatically in the same app via MBean). – Haasip Satang Jun 10 '15 at 17:31
  • @HaasipSatang Ah, I see. In fact, getting an address of an object in 64-bit JVM with CompressedOops is a bit more difficult than described in the article. – apangin Jun 10 '15 at 18:17
  • OK, I'll play around a lil more. At least I know the general understanding was correct then. But probably I need to think of a completely different approach now anyway (coz of the mem spaces). Idea was to tag certain objects at runtime (using JVMTI) and then later on compare them with their older state from the heap dump. Problem is obviously identifying the object I'm having in memory in the older heap dump. Any ideas? Maybe adding a primitive field to each class using BCI might be a solution. Problem with that is Object class can not have any fields. So I thought tagging might be nicer. – Haasip Satang Jun 10 '15 at 21:18
  • Just in case someone else is looking for this: You might wanna check the VMSupport class from [here](http://hg.openjdk.java.net/code-tools/jol/file/6df1a9b2e5da/jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java). This class shows how you can get the address of an object across the different VMs (32bit, 64bit, compressed or uncompressed Oops). Thanks again to @apangin for providing all the good pointers to the right direction! PS: my objects really just moved across spaces between the operations of getting the object address and creating the dump. – Haasip Satang Jun 13 '15 at 17:42
  • Do you wanna reply [here](http://stackoverflow.com/questions/30629014/how-to-get-object-id-as-used-in-heap-dump?lq=1) as well so I accept the answer as all the guidance you gave here pretty much answered that question as well? Thanks again for your help. – Haasip Satang Jun 13 '15 at 17:44