groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Improve Groovy class loading performance and memory management
Date Wed, 18 May 2016 10:26:55 GMT
On 18.05.2016 11:59, Alain Stalder wrote:
> Looking at that code for GlobalClassset below now, the itemsMap is only
> used for two things:
> - put(), where performance is not crucial because it happens only once
> per loaded class (which is relatively expensive anyway)
> - get(), where performance is crucial
> but no iterations or removals etc. necessary.


> Could it work to try get() first without synchronize and if it returns
> null or throws an exception, just try again in a synchronize(itemsMap)
> block? I have no experience with doing such a thing with a
> (Weak)HashMap... Could a synchronized put() fail if there is an
> unsycnchronized get() at the same time?
> I think I will try that unless someone tells me it can't work...?

not safe, no. The trouble is that it can work... for you, in your test. 
But there is no guarantee it will still work on a different machine. And 
then things like this can happen:

What we used to use is ManagedConcurrentMap instead. Or you could try 
using Guava, you can make in there a concurrent weak keyed hashmap. Only 
we cannot use guava for Groovy. The library has just a too high payload

> If it was worth a try:
> Any tips on tests I could run to compare performance of Groovy master
> with this branch (and verify that it is thread-safe)?
> I know there are tests in the benchmark directory of the groovy sources
> - which one(s) could I maybe run for this?

those benchmarks are largely number oriented, they won´t help you. You 
could try for example run many scripts concurrently, using the same 
groovy runtime. That usually gives a rough idea about the performance of 
this part of the code. A verification, that it is thread safe you won´t 
get with a benchmark, only a stress test.

bye Jochen

View raw message