[groovy-dev] GroovyClassLoader, why parseClass method is synchronized ?

[LouMeou]

Hi all,
we embedd groovy (version 2.3.8) to our java application to customize it and
manage business rules.
To do this, more than 100 scripts have been created.

When the application starts, we can /[optionnally]/ pre-compile the whole
scripts.
This is done by our service, by many threads.

It works (I mean all scripts are compiled)
but I notice (using /visualVM/ for example) threads are waiting/are blocked
by the *GroovyClassLoader#parseClass* method.

It looks like coming from /source cache management/, a feature we do not use
in our application.



Note: FYI, the main method we used is



Maybe this is wanted ? necessary ?
Does anybody know how to bypass this ?

Thanks for any help (and sorry for my English !)

Nicolas




--
View this message in context: http://groovy.329449.n5.nabble.com/GroovyClassLoader-why-parseClass-method-is-synchronized-tp5721886.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by LouMeou
Hi all,
we embedd groovy (version 2.3.8) to our java application to customize it and
manage business rules.
To do this, more than 100 scripts have been created.
When the application starts, we can /[optionnally]/ pre-compile the whole
scripts.
This is done by our service, by many threads.
It works (I mean all scripts are compiled)
but I notice (using /visualVM/ for example) threads are waiting/are blocked
by the *GroovyClassLoader#parseClass* method.
It looks like coming from /source cache management/, a feature we do not use
in our application.

[...]

Post by LouMeou
Note: FYI, the main method we used is
Script GroovyShell#parse(final Reader reader, final String fileName);
Maybe this is wanted ? necessary ?
Does anybody know how to bypass this ?

explaining this is a bit complicated... first the Groovy compiler is not
multithreading capable. It has a ton of mutable structures and other
things that prevents this. Given knowledge about your application it is
possible to run multiple instances of the compiler in parallel. But for
this you have to make sure, there are no dependencies "crossing"
compilation threads. Let us for example you have a class A, depending on
a class C, and compile those in one thread. And you have a class B
depending on C as well but you compile this in another thread, then it
is entirely possible that each thread will compile C itself, and if C
leaks out before both are done with the compilation, you suddenly may
get multiple C classes. And that can cause a lot of trouble.
GroovyClassLoader does not have this kind of knowledge, which is why it
forces single threaded compilation.

If you want to bypass this, you should use CompilationUnit directly and
multiple instances of it.

bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[LouMeou]

Hi Blackdrag,
thanks for those explanations, they suit me.

I will try the tips you gave (using multiple instances of *CompilationUnit*)
as base classes are compiled/loaded first.
This to prevent the kind of issues you described.

Thanks again
Nicolas



--
View this message in context: http://groovy.329449.n5.nabble.com/GroovyClassLoader-why-parseClass-method-is-synchronized-tp5721886p5721907.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email