All~ >From my experience, eliminating branch to branch chains produces better JIT-ability of bytecode.
Meaing things of the form: GOTO_A code LABEL_A: GOTO_B: code LABEL_B just eliminate LABEL_A and have everyone go directly to B. Matt On Tue, Feb 24, 2009 at 1:22 PM, Charles Oliver Nutter < [email protected]> wrote: > > Robert Fischer wrote: > > What optimizing efforts are worthwhile on generated bytecode given the > optimizing capabilities of > > the JIT? I'm having trouble finding an explicit or definitive list of > optimizations, but trying to > > be clever about method inlining is pretty clearly wasted effort. I can't > find any documentation on > > it, but I'm assuming the JIT also takes care of constant folding, > strength reduction, and dead code > > removal, since they're so straightforward. Or am I wrong, and the JIT > assumes the compiler author > > applied those filters already? > > Anecdotally, I've found that most micro optimizations to the bytecode > don't make a big difference. I've got bits of Duby's compiler that will > generate slightly different loop or branch logic from javac, and the > performance is no different. But there are a few things that seem to be > worthwhile: > > - General reduction in bytecode size. Simply having less bytecode seems > to have a large effect on how well Hotspot is able to consume the code. > There are also size limitations on inlining code, so less bytecode often > means more inlining. > - Reduction in numbers/complexity of branches. This also plays into > total bytecode size, but I've seen improvements from simply flipping > loops around or calculating jump conditions in aggregate before making a > single jump. > - Outline as much code as humanly possible (as opposed to inlining). > JRuby's compiler originally just emitted all logic straight into the > method body. This turned out pretty badly; it was very slow, and there > was a tremendous amount of duplication. By pulling as much as possible > into static utility methods, bytecode size was drastically reduced and > performance went up substantially. > > > Is it worthwhile to recognize tail calls and turn them into GOTOs, or is > that another thing the JIT > > will take care of? What about loop unrolling? Branch ordering? > > TCO is apparently "done" in the MLVM patchset, but until then avoiding > the recursive call can definitely help. > > > And even if the JIT takes care of things, there's presumably a cost for > having it do them -- is it > > worth applying the optimizations simply to save the JIT the effort and > let it focus on more involved > > work? > > The number one way to "help" the JIT is to keep code bodies as small as > possible...beyond any other technique, this is the one I recommend. > > I can elaborate on specific techniques if you like. We've gone through a > lot of experimentation on JRuby. > > - 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 -~----------~----~----~----~------~----~------~--~---
