3 Replies Latest reply on Mar 12, 2007 11:48 AM by clebert.suconic

    Stripped down reference reports from JVMTIInterface

    brian.stansberry

      I'm loving using JVMTIInterface to generate classloader leak reports (see http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassloaderLeakUnitTestCase) but I'm wondering if it makes sense to add a method that produces a report with a lot of the superfluous chains removed.

      Basically, I'm thinking of something like exploreObject, but instead of writing to a PrintWriter, the method builds up a tree of Node objects that encapsulate the string entry for each explored data point (example class below.)

      As it's building up the tree, if it finds a data point that refers to a java.lang.Reference or to an object that's already been explored, it throws a ref to the node into a Set. When it's gone through all the data points, it iterates over the nodes in the set, calling removeBranch() on each. That will prune all branches from the tree that lead to Reference pointers or to objects that would be gc'd if the real leak is fixed.

      Then call toString() on the root node to get the slimmed down report.

      Does this make sense?



      class Node {
       final String message;
       List<Node> children = new ArrayList<Node>();
       Node parent;
      
       Node(String msg) {
       this.message = msg;
       }
      
       void addChild(Node child) {
       children.add(child);
       child.setParent(this);
       }
      
       void removeChild(child) {
       children.remove(child);
       if (children.size() == 0)
       removeBranch();
       }
      
       void removeBranch() {
       if (parent != null)
       parent.removeChild(this);
       }
      
       void setParent(Node parent) {
       this.parent = parent;
       }
      
       String toString() {
       String result = msg + "\n";
       for (Iterator it = children.iterator(); it.hasNext();)
       result += it.next().toString();
       }
      }


        • 1. Re: Stripped down reference reports from JVMTIInterface
          brian.stansberry

          I've implemented a version of this in the AS testsuite (trunk and Branch_4_2). See org.jboss.test.classloader.leak.clstore.LeakAnalyzer. Added an overloaded exploreObjectReferences that takes a parameter to indicate if it should produce a condensed format report. If not condensed, reference chains that would survive on the condensed report are shown in bold, with the ultimate root in red.

          Not sure at this point if the condensed part works right, but the bold/red bit does, so I know I can make the condensed work simply by not printing nodes if they wouldn't be bold. I'll do that sometime later.

          • 2. Re: Stripped down reference reports from JVMTIInterface
            starksm64

            This looks great. I got the ClassloaderLeakUnitTestCase.testSimpleWar passing by clearing the WebMetaData class loader refs the report showed. The associated root was a ThreadLocal entry that I currently don't see how could exist. Its cleared at the end of every request so either I'm missng somethng or there is another one in the thirdparty layer.

            • 3. Re: Stripped down reference reports from JVMTIInterface
              clebert.suconic

               

              "bstansberry@jboss.com" wrote:
              I've implemented a version of this in the AS testsuite (trunk and Branch_4_2). See org.jboss.test.classloader.leak.clstore.LeakAnalyzer. Added an overloaded exploreObjectReferences that takes a parameter to indicate if it should produce a condensed format report. If not condensed, reference chains that would survive on the condensed report are shown in bold, with the ultimate root in red.

              Not sure at this point if the condensed part works right, but the bold/red bit does, so I know I can make the condensed work simply by not printing nodes if they wouldn't be bold. I'll do that sometime later.


              I will copy the method to JVMTIInterface.