Re: Memory leak in FSClassRegistry.cl_to_type2JCas?

[Marshall Schor <ms...@schor.com>]

I think you're quite possibly right, as the original design didn't contemplate
the use case of lots of classloaders being dynamically created.

Do you have an example of that kind of use case?

-Marshall

On 9/30/2020 4:18 AM, Richard Eckart de Castilho wrote:
> Hi,
>
> 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.
>
> Cheers,
>
> -- Richard

Re: Memory leak in FSClassRegistry.cl_to_type2JCas?

[Richard Eckart de Castilho <re...@apache.org>]

On 3. Oct 2020, at 14:44, Marshall Schor <ms...@schor.com> wrote:
> 
> I think you're quite possibly right, as the original design didn't contemplate
> the use case of lots of classloaders being dynamically created.
> 
> Do you have an example of that kind of use case?

Creation of new UimaClassloaders happens all the time. In PEAR contexts,
these may define new types. So if you work with a lot of PEARs being
dynamically installed/uninstalled, this can happen.

Similar in an OSGI context when bundles are installed/uninstalled.

Cheers,

-- Richard