RFC: regarding metaspace(metadata?) dump

[Ioi Lam]

On 1/12/2023 1:55 AM, Thomas Stüfe wrote:
>
> 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.
> [...]
> 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.
>

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).

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?

I'll give an example here that such a generic dump will not help:

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.

However, if I have more than one indys, how do I find out which 
generated class is related to which indy?

Since the linkage may be implemented differently in each HotSpot 
version, it's not possible to represent that in a portable way.

For this problem, I had to write the findclass() debug method. See 
JDK-8292699. I have some example dumps in the PR 
(https://github.com/openjdk/jdk/pull/9957).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230112/e4a07a18/attachment-0003.htm>