Hi again,
searching for the causes of a sudden increase in script-compile time in
an OSGi application I am now investigating classloading.
Here is the simplified scenario:
OSGi application with lots of bundles, one of which (lets call it bundle
A) uses GroovyScriptEngines to load small scripts for customisations,
these scripts can work with classes imported from other bundles.
There are lots of other bundles to, one of which has some embedded jars
in its bundle-classpath, lets call that one bundle B. And of corse there
is also a groovy-all bundle (from embeddable-dir of binary
distribution). As soon as there is a dependency from bundle B on
anything from the groovy-bundle (like an import of groovy.lang)
the script-compile times (and first execution-times) of the
GroovyScriptEngine in bundle A skyrocket because the jars in the
bundle-classpath of bundle B get accessed like crazy during compilation
and first execution.
I noticed that even though I use the classloader of bundle A as parent
for the GroovyScriptEngine the groovy-bundle gains some dependencies on
my bundles at runtime and that basically creates some sort of
dependency-cycle between the groovy-bundle and bundles A/B which leads
to those exessive reads of the lib-jars in bundle B. All I need in
bundle B is a reference to Closure because there is one class that has
gained a method which accepts a Closure as an argument....
I hope I have explained the situation clearly, does anyone have an idea
or a tip what to do here?
Whats interesting is that this only appears to be a problem in the
deployed application, when I run it inside Eclipse I do not see that
many read-accesses....
regards
Wolfgang Pedot
|