We have the same problem in Jython, including a very old bug (from 2002) reporting this.
We also thought about doing some sort of code splitting for Jython, but punted since the code analysis seems unnecessarily difficult except in the simplest case. We instead implemented a Python bytecode (PBC) VM to run on top of the JVM, since PBC is reasonably well defined. In particular, bytecode offsets are signed 32 bit, so this supports sufficiently large methods ;). Our experimental functionality is just barely documented in http://www.jython.org/jythonbook/en/1.0/ModulesPackages.html#sys-meta-path, and currently relies on using CPython to actually compile to PBC files (.pyc). But the PBC VM works well, without too much overhead given the VM on VM aspect. PBC is also more compact than the equivalent Java bytecode. At some future point we will add support to the Jython compiler to emit PBC, because it can support not only long methods, but also Android and applets without ahead-of-time compilation requirements. We may also revisit the use of a large switch statement and choose to use a polymorphic instruction approach. - Jim On Fri, Sep 10, 2010 at 2:53 PM, Rémi Forax <[email protected]> wrote: > Le 10/09/2010 22:26, Matt Fowles a écrit : > > 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 >> >> > > Like Matt says, I do variable-uses analysis. > > > 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. >>> >>> >> > You can push state on heap only between to block of N lines. > It's a kind of register spilling. > > I also transform loop to function, i.e I cut before the loop > and integrate the loop and the loop body in a new function. > Because I use loop counter, I'm able to know if I need to aggregate > a loop and its inner loop or not. > > > * 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 >>> >>> >> > Rémi > > -- > 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]<jvm-languages%[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.
