Memory leak due to CGLIB 3.2.0 fast classes

[kenwenzel]

I use the method Injector.createChildInjector(...) to create many injectors with different configurations in my application. Each of those injectors is only used for a short period of time and then garbage collected.

Now it seems that for each injector an own set of fast classes is created for each SingleMethodInjector and others. For an example look at:

guice/core/src/com/google/inject/internal/SingleMethodInjector.java

Line 46 in f905d59

final net.sf.cglib.reflect.FastClass fastClass =

These fast classes (or at least meta data about them) are kept within a global map.
The Eclipse Memory Analyzer classifies this as a leak suspect:

One instance of "java.util.HashSet" loaded by "<system class loader>" occupies 671,209,552 (79.21%) bytes.
The instance is referenced by com.google.inject.internal.cglib.core.$AbstractClassGenerator$1 @ 0xfff4c7a0 ,
loaded by "com.google.inject". The memory is accumulated in one instance of "java.util.HashMap$Node[]" loaded by "<system class loader>".

I think it should be possible for Guice to share the fast classes between different injectors.

These are my findings after digging into the problem:

• ByteCodeGen always creates a new fast class generator for every type and member:
  https://github.com/google/guice/blob/master/core/src/com/google/inject/internal/BytecodeGen.java#L245
• FastClass.Generator is a sub class of AbstractClassGenerator
• AbstractClassGenerator supports caching of generated classes:
• https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/AbstractClassGenerator.java#L116
• Maybe I am wrong but the primary lookup key for the generated classes is the FastClass.Generator instance itself
• FastClass.Generator does not implement hashCode() and equals()
• Guice creates a new generator for every type and member and hence the cached class is NEVER used
• This effectively means that Guice creates a new FastClass for EVERY injection point (slow)

My proposed fix:

• use a WeakHashMap in ByteCodeGen to cache ClassLoader -> FastClass.Generator instances
• use the class loader of the target type as key to lookup or create FastClass.Generator instance at this line
  https://github.com/google/guice/blob/master/core/src/com/google/inject/internal/BytecodeGen.java#L245

[kenwenzel]

I've looked at the wrong version of CGLIB (the latest).

The problem seems to be the class name cache of CGLIB v3.2.0 (used by Guice):
https://github.com/cglib/cglib/blob/RELEASE_3_2_0/cglib/src/main/java/net/sf/cglib/core/AbstractClassGenerator.java#L233

The generated class is cached via a WeakReference:
https://github.com/cglib/cglib/blob/RELEASE_3_2_0/cglib/src/main/java/net/sf/cglib/core/AbstractClassGenerator.java#L242

If then a Guice injector is gc'ed and a new one is created the fast classes are regenerated and their names are added to the class name cache. Hence the class name cache grows over time ...

Proposed fix: Switch to CGLIB 3.2.4