Charles Oliver Nutter wrote: [...]
Can you explain in terms of the Groovy codebase what you mean by "the Groovy speed problem"? I may be able to explain what we have done in JRuby for similar situations.
I spend uite some time to get an overview and counted about 20 points were concurrent stuff is involved on the first call of a method. If the method is called again, this is reduced to some volatile access to see if a category is active and some other things. For example to get the metaclass. In case of a GroovyObject this is easy, since the Object itself stores the meta class. In the case of a Java based Object we need to get the metaclass from the global registry, which is more or less a concurrent map. In the best case this is will involve access to a volatile too.
Even if we had method handles (Groovy is based on Java 1.5 atm), I would still have to do things like checking if there is an active category, if the metaclass is still the same and not mutated (ExpandoMetaClass allows mutation)
For the category stuff it might be interesting to look at org.codehaus.groovy.runtime.GroovyCategorySupport#hasCategoryInCurrentThread, which uses an AtomicInteger in the first place and if that check fails we have to get a ThreadLocal storing the real category information.
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite#checkPojoMetaClass() contains the check we do for a cached java method. Something similar is done for method calls on groovy objects.
I just noticed that I can remove that usage AtomicInteger... I guess when Alex implemented that he had a a different usage in mind. Of course all this callsite stuff could be mostly replaced with MethodHandles, but we would still have to check the categories, normally.
not sure this really helps you bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
