On Thu, Dec 17, 2009 at 1:24 PM, Charles Oliver Nutter <[email protected]> wrote: > On Thu, Dec 17, 2009 at 12:17 PM, John Cowan <[email protected]> wrote: >> I proposed a long time ago to add "goto" to Janino, which would remove >> a huge amount of the incentive to generate bytecode directly. The >> proposal was turned down, but the new moderator might be more >> receptive, especially if a patch was provided. (You can do a lot of >> what goto does with "do ... while (false)" and judicious use of break, >> but it's messy.) > > Ideally I should never have to worry about goto; I should be able to > feed something a Java/JVM-aware CFG and know it will produce the best > possible code for me.
I don't understand this. Janino's input is Java 1.4 source code, not a CFG; it's an embeddable compiler. > >> I'm not sure that making Janino do its own optimizations is really a >> win: too-clever bytecode generators, as we know, can cause JITs to >> pessimize the code. But I'm willing to be convinced otherwise. > > I think this is true for small cases, but certainly not for large > ones. For example, sometimes it's just damned useful to be able to say > "inline this code everywhere...no really, just do it". Or in JRuby's > case, to be able to say "treat finals as really finals, finally!" and > not compile multiple accesses as multiple accesses. There's lots of > reasons why doing some up-front optimization can help, since even the > best JVM jits don't do *everything* for us. > > In JRuby's compiler, we're going to do a lot of this on a Ruby level > before feeding it to whatever bytecode generation, but ideally our > bytecode-generating backend would just translate our Ruby CFG into a > rough Java-like CFG and the backend will do additional optimization > passes to produce the best-possible bytecode. > > Another optimization a good compiler backend could do for us would be > generating smaller synthetic methods if basic blocks of code appeared > frequently in a very large body. Right now, javac and friends are > pretty dumb...you feed it a big chunk of code, it puts it into a big > method. But if it were smart about splitting up blocks into synthetic > submethods, we'd have mo' betta inlining possibilities, smaller units > of code, and generally better performance. > > There's a lot of opportunity here. > > - 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. > > > -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures -- 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.
