John~ That depends on how you squint. I never bother with Janino's parser; I walk my AST and generater a Janino AST and then cook that directly. I added the method
SimpleCompiler.cook(Java.CompilationUnit compilationUnit) to the API expressly for this purpose. Matt On Thu, Dec 17, 2009 at 2:49 PM, John Cowan <[email protected]> wrote: > 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]<jvm-languages%[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]<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.
