Jochen "blackdrag" Theodorou wrote:
> 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.
OK. :)
> [...]
> > 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.
Ah, I see. Probably no sensible way around that for security reasons...
> > As for garbage collection, below JDK9 using concurrent mark and
> > sweep collector you can enable class unloading and it can happen more
> > often.
OK, would explain what I observed with JDK 9. To me this is already an
important improvement.
> > 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
Makes sense, I agree.
Best wishes,
Alain
