groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Groovy parser very slow when using ImportCustomizers
Date Thu, 17 Dec 2015 08:16:18 GMT


Am 17.12.2015 um 03:59 schrieb Goo Mail:
[...]
> Whatever manipulation is going on there was apparently not intended to
> performed on shared objects, but I was able to make it work by
> serializing all calls to the Groovy parser until at least one good parse
> has been completed. After the first good parse, the types in the
> ImportCustomizer seem to be fully resolved and I can again parse scripts
> on multiple thread simultaneously with the shared ImportCustomizer.

ResolveVisitor will resolve only unresolved class objects, so that 
strategy should work. Even better of course would be to be able to add 
imports using resolved classes

> With all of that having been written: is sharing the same
> ImportCustomizer across different classloaders and parse sessions still
> a good idea?

if you can ensure everything is resolved and if you are aware, that you 
are sharing an object concurrently, that is not written for that (even 
with just reading you can get into safe publication problems). So you 
may have to ensure memory barriers are passed

> I like the performance improvement that sharing the
> ImportCustomizer provides, but the mutability aspect seems like more of
> an inadvertent feature and/or issue that might not have been intended by
> the Groovy designers.

every part of the Groovy AST is basically mutable and not intended for 
multithreaded use.

bye Jochen

Mime
View raw message