Charles Oliver Nutter wrote: > Now this bytecode is pretty tight. There are some special-case methods > for Fixnum 1 and 2, CallSite objects to encapsulate some boilerplate > call-wrapping logic, and "setPosition" calls to update the Ruby stack > trace, but otherwise we've managed to boil it down a lot. And it's still > a lot of code. I've been doing a bytecode audit recently to make sure > all bytecode generated is as clean as possible, and this is the result > at the moment (trunk code). What's a comparable fib method in Groovy > look like with the new call site stuff?
I had an itch, so I updated my working copy of groovy and gave fib a compile, and I must say I'm very impressed with the progress. The bytecode is probably about as tight as JRuby's. You've got CallSite in all the same places, Integer caches, basically all the same stuff as JRuby's output. Kudos for that, it's a vast improvement over the old code. It's amazing how similar the bytecode looks to JRuby's now...we're truly living in parallel dimensions. There's a few comments and questions: - 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. - 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. Any thoughts on these? 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. 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? - Charlie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
