Charles Oliver Nutter schrieb: [...] > - JRuby currently doesn't do "multihosting" using the classloader > hierarchy; instead, we have a simple org.jruby.Ruby object that > represents a given runtime. This means we pass Ruby through most stacks > to get at things like Fixnum caches. Statics are most definitely out in > that scenario. We might be able to do the classloader version in the > future...we shall see. I would suppose the current system in Groovy > means you must make sure not to have Groovy at multiple levels in the > classloader hierarchy, yes? It seems like with all those statics there's > a strong change of having two Groovys lower in the hierarchy load > something from higher up and step on each other. I've wanted to try > isolating JRuby instances by classloader, but there hasn't been time.
Two active Groovy versions means to have a parent knowing Groovy and a child knowing a different Groovy. That also means the class loader is violating the loader constraints, or at last they way a classloader should work. But ok, you get more or less the same scenario with siblings in the classloader tree. As long as these two do not try to transport object to each other there is no problem. If they do, then GroovyObject from the one is not recognized by the other. That means the MetaClass will be disabled. But since the class is besides this more or less a Java class, it will be handled as such. I think that is perfectly legal. We once had problems with this kind of scenario, because we did create a Reflector for each class. You can imagine this as a class with a single method with a giant switch in it making direct method calls. So to say.. poor mans MethodHandle. since we make direct method calls we have to do casts, which will cause class loading, and class loading by name. Now if there is something unusual in the classloader tree, this often failed with very strange exceptions. Most of them caused by class duplication and others. So we decided to remove the Reflector, not only because of that problem, but also because it wasn't any faster than Reflection anymore. Since then I am a bit careful with class generation at runtime. Besides that... when you start Groovy from the command line, then you usually have two Groovy active, because RootLoader will load Groovy again, even though it is part of Groovy. But of course nearly nothing of the other Groovy is used. > - JRuby takes some level of perf hit from the pre/post-method setup and > the method preamble, which loads more into local variables than does > Groovy's. This is largely because of a set of features Ruby has that > require more than what Groovy provides; namely, nested closures have > heap-based nested scopes, public/private/protected are methods, a > binding can be pulled off at any time and passed around to access local > variables and other state, and several more. They're features that give > great flexibility to Ruby, but which are extremely difficult to optimize > for. I have more tricks I'll be putting in future versions of JRuby, but > they'll take a bit of time. Ruby's a tough language to implement. I can imagine [...] > I ran through some of the Alioth benchmarks, and they're definitely a > lot better. 1.6 ought to be a good release for you. we hope so ;) > One question on CallSite, and admittedly I could probably get this from > digging in the source... When I followed the discussions about call > sites a few months ago, it seemed like they had to be constructed by > hand on a case-by-case basis for specific types. So for example, you had > to write the CallSite code to handle Integer +, -, *, etc, and if you > didn't hand-write a CallSite, it would not be available. Has that changed? I think you got that only partially right. We have binary operations on the call sites, these can be linked directly to methods that do for example int+int. The advantage is that you do not have to create an extra array to store the arguments. that already can mean quite a difference. Anyway, int+int is directly available as such a binop, thus it can be used without transformations and without Reflection from the callsite. If it is not available, the we fall back to the normal Reflection based code. Such an optimization would maybe not needed if we had MethodHandles. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.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 -~----------~----~----~----~------~----~------~--~---
