groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Lock contention in Groovy Shell interpreter under high load
Date Thu, 10 Aug 2017 22:26:23 GMT
On 10.08.2017 20:40, Aman Jain wrote:
> Thank you, Jochen! It is very helpful.
> 
> So, what I understand is that I can cache either the Script (evalScript) 
> *or* Script Class (evalScript.getClass()) instances in my application 
> code and reuse them.

well, since you put the "or" in bold I tend to think you think this is 
an exclusive choice. You can use both if you want. Depends really on if 
it makes sense for you or not. You will always have one class, you will 
always need x instances for x parallel operations. If you cache the 
instance, you indirectly cache the class. The only factor then is if I 
make the instances each time fresh, or produce only x. Producing only x 
instances will have a little bit better results, but then you have to 
have a clean up strategy for the pool as well. Instance and class go 
together... so not really either-or... but of course nothing is really 
for free

> I tried by caching Script Class (evalScript.getClass()) instance and 
> reuse it in my code and the results are much better. For each thread, I 
> am retrieving the Script Class from my cache and generating its new 
> instance by calling scriptClass.newInstance()

ok

> Does above caching of Script Class (evalScript.getClass()) instance in 
> my application code can cause any memory leak or delayed clean-up of the 
> generated classes and meta classes (as you mentioned in your last point)?

nothing to worry about. The problem starts when you have potentially 100 
thousands of such classes (*not* instances)

bye Jochen

Mime
View raw message