[jira] [Resolved] (UIMA-6276) Potential memory leak in FSClassRegistry

["Richard Eckart de Castilho (Jira)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Eckart de Castilho resolved UIMA-6276.
----------------------------------------------
    Resolution: Fixed

> 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
>            Priority: Major
>             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)