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
