byte-buddy
                                
                                 byte-buddy copied to clipboard
                                
                                    byte-buddy copied to clipboard
                            
                            
                            
                        ResettableClassFileTransformer.reset doesn't clean up the klass in the metaspace
I use the following codes to apply some Advice to the expected classes
new AgentBuilder.Default()
                .with(DISCARDING)
                .with(RETRANSFORMATION)
                .with(DECORATE)
                .disableClassFormatChanges()
                ...
                .installOnByteBuddyAgent()
and use the ResettableClassFileTransformer#reset to restore. But I find the size of the metaspace keeps increasing if I keep installing the agent and resetting it serveral times.  So I use the jcmd PID GC.class_stats to print the detailed information about the memory usage of each loaded class and find several matched classes that exist in the metaspace simultaneously.
Index Super InstBytes KlassBytes annotations    CpAll MethodCount Bytecodes MethodAll    ROAll    RWAll    Total ClassName
927  8363        88       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8479  8363         0       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8480  8363         0       1568           0     1960           8       119      2112     1384     4776     6160 org.apache.flink.table.runtime.operators.sink.SinkOperator
8481  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
8482  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
8483  8363         0       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8484  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
8485  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
8486  8363         0       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8487  8363         0       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8488  8363         0       1568           0     2144           8       119      2112     1400     4944     6344 org.apache.flink.table.runtime.operators.sink.SinkOperator
8489  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
8490  8363         0       1568           0     2144           8       143      2360     1440     5152     6592 org.apache.flink.table.runtime.operators.sink.SinkOperator
I just wonder whether the  ResettableClassFileTransformer#reset can clean up the rewritten classes.
If a method is active within an infiite loop, it can never be unloaded. Might this be the case? I would not know how Byte Buddy is causing this. I would assume the same would apply when using vanilla transformation APIs.
Thanks for your feedback! I think it might be the case you menitoned. After waiting for a long time, I redump the metaspace and I find it only has one class...
I just want to ask some questions: if we use the Instrument API to redefine or retransform a loaded class, does it means we only have one clazz in the metaspace? If the metaspace is not enough, will the byte-buddy stop and does't crash the JVM?
Metaspace just grows. It's possible two versions exist in parallel if one remains active, e.g a loop is never left.