Charles~ 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.
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. Matt On Fri, Sep 10, 2010 at 4:21 PM, Charles Oliver Nutter <[email protected]> wrote: > So friends, what's the latest tips and tricks for dealing with code > size on the JVM? There's various issues I'm dealing with: > > * Some Ruby methods are gigantic and difficult to break into pieces > * My recent dynamic optimization work increases code size because it > has a static and dynamic path for profiled calls > * 64k should be enough for anyone...but it's not > * Hotspot will fail to even compile methods over a certain > size/complexity, and obviously avoids inlining many smaller bodies > > Before I embark on a quest to try to break out each basic block in my > code and find a clever way to pass around local state, are there any > recommendations? > > A few strategies I already employ: > > * Lots of static methods for boilerplate pieces. Works great, until > you end up with one of those methods failing to inline completely as > in my other thread. > * For long, flat bodies, I split every N lines and just pass all > current state through. Only works for flat bodies, though, and I have > to do some deopt to maintain local state on the heap. > * I size-limit most jitted bodies to be under 10k of bytecode, since > it's unclear at what point Hotspot will fail to optimize it well. > > And I've play with damn near every Hotspot flag for increasing inline > size, "small code" size, max graph node counts, and so on. For > languages like JRuby that have a lot of logic involved in doing > dispatch, this is a serious problem. > > Of course I know method handles will do a lot (especially if they are > not part of the inlining budget for a method), but I need non-Java 7 > answers too :) > > - 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. > > -- 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.
