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
