MetaSpace and StackMapTable

[Ioi Lam]

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 #..
x:

     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.

Thanks
- 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: 
> https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.10.1
>
> 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 *
>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/verifier.cpp 
>>>
>>>
>>>
>>> Thanks,
>>> John.
>>>