The classes generated by the ByteBuddyProvider can only be unloaded if the classloader will become unreachable. If you dont use a dynamic Classloader the classes cannot be thrown away and will stay in memory permanently. The problem we run into especcially in testing is that the memory runs full with classes generated by the ByteCodeProvider. This can somwhat be worked around by overriding #resetCaches to not actually resetCaches-> clearing the Caches is good if you use a deployment classloader, but if you dont have a deployment classloader it is actively bad for you… However that still leaves a few issues: #getReflectionOptmizer creates a “fastClass”. this class is currently not cached, but it should be. It seems not optimal to me to create the “fastClass” before actually checking the acessors-> if there is a problem with the acessors it ends up loading a new class in the jvm with no befits at all. I attached 2 semi automatic testcases: Excpected: resources needed stay the same, regardless if ReflectionOptimization is uses or not . Actual: more and more classes are added to the jvm |
