MetaSpace and StackMapTable

Ioi Lam ioi.lam at
Thu Jun 11 20:23:09 UTC 2020

Hi John,

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

     astore #100
     astore #101
     aload #..
     aload #..
     aload #..
     aload #..
     aload #..
     aload #..
     aload #..

     if<xxx>  x

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.

- Ioi

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.
>> Thanks,
>> David
>> 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 
>>> automatically
>>> 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 
>>> switch
>>> class verification off (-noverify) *MethodAll* reduces to 55MB.
>>> I'm interested to know:
>>>   - does the JVM free memory held in MetaSpace by StackMapTable 
>>> attributes
>>> 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 
>>> doesn't
>>> seem possible *ClassVerifier::verify_stackmap_table *
>>> Thanks,
>>> John.

More information about the hotspot-runtime-dev mailing list