groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Improve Groovy class loading performance and memory management
Date Sun, 15 May 2016 07:14:20 GMT
On 14.05.2016 09:54, Alain Stalder wrote:
[...]
> Lazy initialization of MetaClass:
>
> I could well imagine that this makes a noticeable difference, but you
> are probably much better able to estimate this offhand.
>
> If it made a noticeable difference, I guess it would also impact heap
> consumption due to loaded Groovy classes (less MetaClass instances) to a
> similar degree.

less meta classes is always good.

> Maybe measure in some way for how many and which classes MetaClass is
> actually ever needed/used? Maybe a modified Groovy test version that
> somehow records this and then use this Groovy test version in some
> "realistic" setups where lots of Groovy classes are loaded and
> instantiated? (Just thinking aloud...)

well... as soon as you access a property or call a method, you will most 
likely need a meta class of that class. What could be profit are small 
scripts. In case of Closure you will loose that already, because even if 
it does only return something like 42 and thus does not need to make a 
dynamic call, the call to the method containing that code is called 
dynamically, thus you need the meta class. On the other hand we have 
here ClosureMetaClass, with a smaller footprint exactly for that.

> Garbage collection without setting a limit on Metaspace:
>
> For the simple Java test class JavaFilling, the VM collected unused
> classes without having to set MaxMetaspaceSize, in the case of
> GroovyFilling this was not the case.

because of the use of SoftReference. The problem with using 
WeakReference for example is, that then you will get lots of meta class 
initializations, which can be a big impact on performance. ClassValue is 
supposed to make this better though

> I lack experience with garbage collection of "pure" Java classes, so I
> am not sure if the behavior observed with Java is only like this for
> very simple classes with little dependencies on other loaded classes. If
> that was so, I guess there would be very little that could be gained
> from trying to change Groovy behavior.

Well, in Java the classes are not referenced but structures as complex 
as we have to use like the table/classinfo/metaclass system. ClassValue 
is suppose to help here.

> One approach could be to look closer into that, maybe run ClassGCTester
> with some "pure Java" library JARs and load classes from there and
> observe Metaspace?

frankly, most Java applications do not even use more than one 
classloader, thus class unloading is of no  question there. That goes 
even as far as not being able to use the standard garbage collector if 
you want classes being unloaded properly. Well, this changed with JDK8. 
Even a JSP web app, does use a very limited amount of classes (but of 
course more class loaders than a standard Java app).

> Or maybe approach it the other way: Use a modified Groovy test version
> that *does* use a WeakHashMap, just to see if that would make a
> difference here and if investing more effort into that direction could
> amount to anything?

WeakHashMap cannot handle concurrency. Each and every access would have 
to be synchronized. In a simple application with GUI you can already 
have more than one thread operating potentially causing the creation of 
a meta class.

bye Jochen

Mime
View raw message