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].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
