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.
yes
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: https://bz.apache.org/bugzilla/show_bug.cgi?id=50078
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
