MetaSpace and StackMapTable

[Harold Seigel]

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