uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Memory leak in FSClassRegistry.cl_to_type2JCas?
Date Wed, 30 Sep 2020 08:18:04 GMT

while looking into solutions for UIMA-6243, I have stumbled across this field in FSClassRegistry:

   * Map from class loaders used to load JCas Classes, both PEAR and non-Pear cases, to JCasClassInfo
for that loaded JCas class instance.
   *   key is the class loader
   *   value is a plain HashMapmap from string form of typenames to JCasClassInfo corresponding
to the JCas class covering that type
   *     (which may be a supertype of the type name).
   *     Key is JCas fully qualified name (not UIMA type name).
   *       Is a String, since different type systems may use the same JCas classes.
   *     value is the JCasClassInfo for that class
   *       - this may be for that actual JCas class, if one exists for that UIMA type name
   *       - or it is null, signalling that there is no JCas for this type, and a supertype
should be used
   * Cache of FsGenerator[]s kept in TypeSystemImpl instance, since it depends on type codes.
   * Current FsGenerator[] kept in CASImpl shared view data, switched as needed for PEARs.

  private static final Map<ClassLoader, Map<String, JCasClassInfo>> cl_to_type2JCas
= Collections.synchronizedMap(new IdentityHashMap<>());  // identity: key is classloader

It seems to me, that this field is a memory leak, in situations where (lots of) classloaders
are dynamically created.
So the classloaders become the key of the field causing them and probably the classes that
were defined through them to
never be garbage collected. 

Is this correct or am I missing something?

IMHO, this should be a weak map.


-- Richard
View raw message