<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    On 1/12/2023 1:55 AM, Thomas Stüfe wrote:<br>
    <blockquote type="cite" cite="mid:CAA-vtUzNSb3R65aDswRN_zcs9iGYfw9RBuh7=VL9cVBqG7Hc0Q@mail.gmail.com">
      
      <div dir="ltr">
        <div class="gmail_quote"><br>
          <div>If standardization is the goal we take seriously, we'd
            need to carefully choose the information we expose, limiting
            them to those that are stable. That limits the usefulness of
            the command. <br>
            [...]<br>
            Heap dump is a good example of the limits of this approach,
            since the sheer size of data can make them cumbersome and
            expensive to get. There is a niche for tools that quickly
            tell you what you need, without a lot of fuss, runtime
            costs, and intermediate steps. And that help you along the
            way of analysis.<br>
          </div>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    There's one big difference between dumping the heap vs metaspace.
    The contents of the Java objects are well defined, and have a very
    limited set of types (primitive types plus references). This makes
    it very easy to write tools to analyze a heap dump and we can
    guarantee that such tools will work for future versions of JDK
    (well, maybe some mods are needed when we have value types).<br>
    <br>
    However, there is no spec for the metaspace object layout. We
    *could* limit the data to just those specified by the JVM spec
    (i.e., just print out the equivalent of a .class file for every
    loaded class). If we do just this, what kind of use cases can
    benefit from it?<br>
    <br>
    I'll give an example here that such a generic dump will not help:<br>
    <br>
    I wanted to analyze the linkage of invokedynamic instructions. If we
    had a metaspace dump, it would solve one of my problems -- indys are
    linked using generated classes, which aren't available on the
    classpath. So with a metaspace dump, I can get to the generated
    classes.<br>
    <br>
    However, if I have more than one indys, how do I find out which
    generated class is related to which indy?<br>
    <br>
    Since the linkage may be implemented differently in each HotSpot
    version, it's not possible to represent that in a portable way.<br>
    <br>
    For this problem, I had to write the findclass() debug method. See
    JDK-8292699. I have some example dumps in the PR
    (<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/9957">https://github.com/openjdk/jdk/pull/9957</a>).<br>
    <br>
  </body>
</html>