Thread dumps as XML


News: Thread dumps as XML

  1. Thread dumps as XML (7 messages)

    Alexandre Rafalovitch talks about how thread dumps look different between the various JVMs, and within versions of the same JVM.

    Most commercial tools work with the JVMPI debugging interface to access thread information.

    Alexandre proposes that we standardize an XML Schema, and allow thread dump generation to this One Format. This would allow tools to work with thread information at a later date, and would allow simple debugging devices such as XSL.


    "By converting the various thread-dump formats into the unified XML format, we can increase portability of thread-dump analysis knowledge and visualize the relations previously hidden in the bulk of data. Additionally, as there are more XML/XSLT tools and experts than Java thread-dump experts, many more people can contribute to creating useful statistics and visualizations."

    Read Looking at Thread-Dumps

    Threaded Messages (7)

  2. I would agree with value of unified format but please leave XML alone.

    Look how nice the conclusion looks without XML: By converting the various thread-dump formats into the unified format, we can increase portability of thread-dump analysis knowledge …...
  3. I agree[ Go to top ]

    I believe creating the thread dumps into a unified format such as XML will allow us to share that information in a more proficient manor. XML would work perfect in this instance. Allow us to create multiple formats of the dump easily. Another plus point to the XML approach is that reading the thread dumps ourselves would be quicker and more descriptive.
  4. I agree[ Go to top ]

    Great idea!

    Does anybody know a tool/library that can be used to convert the thread dump (txt) into a well formed XML document?

    Kind regards,
  5. Disagree[ Go to top ]

    Backing up the first comment,
    this really shouldn't be in xml.

    A standardized txt format would suffice;
    those that wished to convert this to an
    XML format could do so.

    Introducing a dependency on xml into
    the JVM is an unnecessary step.
  6. Disagree[ Go to top ]

    Introducing a dependency on xml into the JVM is an unnecessary step.
    No one's requesting that package java.lang depend on package org.xml. Using String.class has always been sufficient to compose an XML document.
  7. Hi,
    I had written the original article and just wanted to comment on the discussion so far.

    1) Tool availability: There was a slight problem with dev2dev and the tool was not linked in. You can down download the tool from the article link.

    2) Dependency: I am not advocating for XML format to be a default JVM output. That would not be efficient to generate and complex to implement. Additionally, different JVMs expose different attributes of their threads (e.g. thin thread id). Even if multiple vendors agreed to use the same format, they are then stopped from adding new information easily. And I would prefer more unstructured useful information in the dump, rather than less of the slightly more useful one.

    3) XML or not XML: The problem with universal structured text format is that its ultimate target is human. Which is fine if you can identify all the dependency by eyeballing the text, but if you want to get a small subset of information only (e.g. deadlocks), you are back to trying to reparse the text (manually or automatically). One of the scripts I have, does generates the plain text form. So, if you really don't want to deal with it, treat the tool as black box (with xmlstarlet thrown in) and delete the xml after doing two step generation into the text. And finally, just a thought experiment. What happens if we do define a universal text format, develop the tools to work with that and then a JVM (e.g. JRockit) introduces a new thread status such as 'time-in-waiting-state'. Do we ignore it, even though it would be extremely useful? Do we introduce it as an optional component in the text format (complicating and breaking the parsers) or do we add it into the text format as compulsory element with a default value (breaking all existing parsers again). With XML, you could add the new attribute or even element and most of the scripts will ignore it until you have time to fix them.

    Hope this makes my point of view a bit clearer. Additionally, I am scheduled to present at JavaONE 2004 on how to troubleshoot the application servers using the thread dumps. I will be using my tool there, possibly with some additional scripts.

  8. Different approach[ Go to top ]

    I have seen a tool that uses a different approach. The Stack Trace tool from exports the thread dump information to any Java IDE supporting JPDA debugging. For some JVMs it exports the monitor information too. This way you can use the Threads and Monitors view in Eclipse to detect deadlocks for example. I personally like this tool because it can get thread dumps from Windows services and programs started with javaw.exe.