MetaSpace and StackMapTable
ioi.lam at oracle.com
Thu Jun 11 20:23:09 UTC 2020
The "jcmd <pid> GC.class_stats" command has been removed from JDK 15,
but it was available in JDK 8 ~ JDK 14. I tried a few programs with
earlier JDKs, and the amount of stackmap data is relatively small. For
example, JDK 8 + Eclipse shows:
$jcmd 13360 GC.class_stats StackMap,MethodAll,Total
1761552 42443744 88741440 Total
2.0% 47.8% 100.0%
Index Super StackMap MethodAll Total ClassName
So stackmaps are only 2% of all class meta data.
Since you see much a higher ratio (45MB StackMap out of 100MB
MethodAll), I wonder if your generated methods have a very large number
of local/stack variables at branch targets. Something like
You will end up having a large stackmap at bytecode offset x.
If that's indeed the case, it will also affect the performance of
JIT-compiled code as well.
On 6/11/20 12:35 PM, Harold Seigel wrote:
> Hi John,
> Thank you for your inquiry.
> The JVM does not free the StackMapTable Metaspace memory after
> verification because the StackMapTable information is needed by the
> JVMTI RetransformClasses support.
> Also, it is not possible to have just one StackMapTable entry per
> method. Each stackmap table entry represents the verification type of
> the expected stack and local variables at particular spots in a
> method's bytecode, such as at the beginning of a basic block. Since
> the expected stack and local variables differ throughout the method,
> different entries are needed. For more information about how stack
> maps are used, see:
> Thanks, Harold
> On 6/10/2020 10:35 PM, David Holmes wrote:
>> Hi John,
>> Re-directing to hotspot-runtime-dev. Please drop the discuss mailing
>> list in replies.
>> On 11/06/2020 6:03 am, john bergin wrote:
>>> Hi all.
>>> I'm generating a bunch of classes at run-time with ASM (which
>>> generates StackMapTable attributes) and when all the classes are
>>> loaded the *MethodAll
>>> *(bytecodes, StackMapTable, ...) column from *jmap -clstats *tells
>>> me that
>>> all classes account for about 100MB. When I generate the same
>>> classes with
>>> ASM but tell it *not* to compute the StackMapTable attributes and I
>>> class verification off (-noverify) *MethodAll* reduces to 55MB.
>>> I'm interested to know:
>>> - does the JVM free memory held in MetaSpace by StackMapTable
>>> after class verification and a full GC? My testing shows it doesn't.
>>> - is it possible to generate one StackMapTable entry for each
>>> method that
>>> would satisfy the verifier? I had a quick look at the code and it
>>> seem possible *ClassVerifier::verify_stackmap_table *
More information about the hotspot-runtime-dev