The JarArchiveComparator keeps way more stuff in memory than it would actually need, and it has caused some issues in our CI pipeline due to memory/GC issues.
It first loads every class from 2 jars into memory into both the javassist ClassPool and a LinkedList, and then applies the filters to create another list of filtered classes.
Instead, we could apply the filters right away within createListOfCtClasses. Classes that did not pass the filter should also be removed from the ClassPool, which can be done by creating a subclass like this:
public class MyClassPool extends ClassPool {
public void remove(CtClass ctClass) {
removeCached(ctClass.getName());
}
}
The
JarArchiveComparatorkeeps way more stuff in memory than it would actually need, and it has caused some issues in our CI pipeline due to memory/GC issues.It first loads every class from 2 jars into memory into both the javassist
ClassPooland aLinkedList, and then applies the filters to create another list of filtered classes.Instead, we could apply the filters right away within
createListOfCtClasses. Classes that did not pass the filter should also be removed from theClassPool, which can be done by creating a subclass like this: