Java agent autoprobe analyses classes as loaded and instruments if required by PBDs. In case where class is instrumented, will both original and instrumented versions of byte code remain in Java metaspace, or will space used for the original byte code be freed to allow for later garbage collection.
When instrumenting microservices running in Pivotal Cloud Foundry (PCF), some projects have been using GitHub - cloudfoundry/java-buildpack-memory-calculator: Cloud Foundry JVM Memory Calculator to calculate metaspace requirements, and find that microservice metaspace usage without DX-APM Java agent was about 20k and with DX-APM Java agent it was 30k. This increase may not normally have been noticeable, however same app was using a lib that included native code and the way the lib was used caused memory leak in memory area used by native code (I assume this area is metaspace).
Is permanent increase (beyond the trivial amount required for the extra byte codes inserted by autoprobe) in Java metaspace inevitable, or will the memory used to store the original (uninstrumented) byte codes be freed eventually?
Whilst this issue has arisen in agent running in PCF, I assume metaspace demands of the Java agent would be common across all Java environments (at least since introduction of metaspace). It that assumption reasonable?
DX Agents
Analysis from Development
Java agent autoprobe analyses classes as loaded and instruments if required by PBDs. In case where class is instrumented, will both original and instrumented versions of byte code remain in Java metaspace, or will space used for the original byte code be freed to allow for later garbage collection.
[DEV] - the JVM should free up the classes for the old one at a time when it runs the compaction.
Is permanent increase (beyond the trivial amount required for the extra byte codes inserted by autoprobe) in Java metaspace inevitable, or will the memory used to store the original (uninstrumented) byte codes be freed eventually?
[DEV] - the uninstrumented byte codes should be freed up however it is based on JVM behavior. Ideally it should deallocate.
Whilst this issue has arisen in agent running in PCF, I assume metaspace demands of the Java agent would be common across all Java environments (at least since introduction of metaspace). It that assumption reasonable?