Am 01.09.2015 09:18, schrieb Alain Stalder: [...]
I saw no difference with Groovy 2.4.4 compared to 2.2.2 or 2.1.9, in my cases garbage collection worked once PermGen space resp. MetaSpace became sparse, class loaders and their classes were then collected, both with Oracle/Sun JDK 6 and 8.
I think your scenario is different. You unload/load classes, yes, but the Groovy runtime stays. The problem there was about the runtime not unloading. Classes of child loaders to the loader of the runtime can still be unloaded in most cases.
[...]
Overall a bit disappointing that at the age of about 20, the JVM is not able to handle dynamic class loading and especially garbage collection of class loaders and loaded classes efficiently, i.e. automatically and with relatively little performance overhead.
If you would not have to verify the classes it could be done much faster. As for garbage collection, below JDK9 using concurrent mark and sweep collector you can enable class unloading and it can happen more often.
Pretty bad for a dynamic language like Groovy that always compiles to classes in the JVM... :(
depends on what you compare with. Sure... if you for example think about templates and a webserver using the template to produce the pages, you need something fast. And a String based solution for example can here be pretty fast. But if the page is called often, a class based solution can become faster again. So you start optimizing for your cases. Same for the JVM
bye blackdrag -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/
