On Fri, Sep 10, 2010 at 4:26 PM, Matt Fowles <[email protected]> wrote: > Not to add to your woes, but argument length limits also bite us > periodically. The server JIT will refuse to compile any argument with >>32 words of arguments, since we make heavy use of value types, we run > afoul of this one fairly frequently.
Yes, I think you mentioned this to me at JVMLS. It's an unfortunate limitation...obviously a bad compile would still be better than no compile. We have nowhere near 32 arguments anywhere in JRuby (we arity-split only up to 3 arguments, though the new dynopt JIT could perhaps do better), but there's a potential to hit that if we start trying to break up method bodies more intelligently, since ideally we'd pass along local variables unboxed (and there could be arbitrarily many variables to pass). > We try to do all the same things you do (with varying degrees of > success). We also do a bunch of work to isolate functions based on > the data they manipulate, so we can pass subsets of the state to > different functions. Yeah, the area I want to start exploring would leverage the (limited) escape analysis that Hotspot and JRockit (and J9?) can do today. Specifically, it should in theory be almost free to do multiple returns using a non-escaping "struct", or to pass multiple arguments to an always-inlined utility method as a struct or array, if escape analysis is doing its job. The key with getting EA to work is making sure (REALLY REALLY SURE) that there's no path through which the intermediate structure could escape or get passed to a non-inlined call. Of course, we can't guarantee that any calls inline (ahem, @Inline please) so it's a bit like playing the Theremin...if you're off by a bit in any direction, sour notes result. Still, I think it's a promising avenue, especially for something like your case where you are hitting argument count limits. Try a 32-field struct that is *only* used to pass from one synthetic method to another (and then immediately unboxed and discarded/nulled), and see if EA is able to eliminate it. - 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.
