ArchiveApiTypeContainer retains references to FileSystem forever

[laeubi]

org.eclipse.pde.api.tools.internal.model.ArchiveApiTypeContainer has a static field JRTS, this currently prevents them from being garbage collected.

@iloveeclipse as JDT is also suing the FileSystem, is this the right pattern to use it?
@vik-chand why do we need special handling here and can't use JDT as in the else clause?

[merks]

It looks like JDT has a map that keeps wrappers (org.eclipse.jdt.internal.compiler.util.JrtFileSystem) around them around forever too, i.e., org.eclipse.jdt.internal.compiler.util.JRTUtil.getJrtSystem(File, String) uses org.eclipse.jdt.internal.compiler.util.JRTUtil.images which is static.

[laeubi]

@merks see

• JRTUtil.getJrtSystem(...) permanently consumes a large amount of memory eclipse-jdt/eclipse.jdt.core#1526

but I already clear that map, still then ApiTools has references to the file system I try to find out why currently even if I shutdown the framework the classloaders are not reclaimed, and suspect that here is a cyclic reference inside a "system object", maybe it is not the root cause but I see these references to pile-up after some runs.

[HannesWell]

It looks indeed very similar to what's already done in JDT.
Maybe even eclipse-jdt/eclipse.jdt.debug#294 could be generalized a bit more to also cover the cases of the API-tools here?

I havn't checked it in full detail, but some caller paths again lead to a IVMInstall (in a convoluted way). So maybe if this is restructured a bit, the JDT API to be can be used here directly.

[HannesWell]

The own cache in PDE has been removed with #1359.
So I think we can consider this done (at least at PDE side).