Richard Eckart de Castilho created UIMA-6276:
------------------------------------------------
Summary: Potential memory leak in FSClassRegistry
Key: UIMA-6276
URL: https://issues.apache.org/jira/browse/UIMA-6276
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Reporter: Richard Eckart de Castilho
Assignee: Richard Eckart de Castilho
Fix For: 3.2.0SDK
While looking into solutions for UIMA-6243, I have stumbled across this field
in {{FSClassRegistry}}:
{code}
/**
* 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
{code}
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. This
could e.g. happen in a situation where PEARs are often installed / uninstalled
or where resource managers with lots of different extension classloaders are
used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
