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'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.
