On Oct 21, 3:59 pm, Peter Recore <[EMAIL PROTECTED]> wrote: > I don't think "mistake" is the right word there. I'm not an expert on > Java Compilers and JVMs, but I'll go out on a limb here and risk > embarrassing myself - my gut feeling is that Java is much easier to > compile into javascript than random bytecode is. GWT makes aggressive > optimizations based on information it can infer from java semantics. > If GWT had to generalize to work with any possible bytecode, I doubt > the resulting javascript could be as efficient.
I work on the GWT compiler, and I agree with your conclusion but not with the reason. The issue is more the combination of: - the output format is an expression language with general nesting, while bytecode is more like a three-address intermediate representation (IR) - current JS vm's have terrible optimization, though that is changing - output size is very important for GWT, which isn't changing It would be bad to emit code that looks like this: var t1, t2, t3; t1 = bar; t2 = foo(t1); t3 = baz; return t2 + t3; You really want to emit this, instead, which is both shorter and, on a non-optimizing JS VM, faster: return foo(bar) + baz; If GWT took bytecode as input, then it would need to be able to transform code that looks like the former into code that looks like the latter. This has advantages other than being able to take bytecode as input, so it might be worth looking into. However, it would take a significant amount of work -- a man-month perhaps -- to add this transformation to the compiler, and thus far there have always been competing features that seem more important. The reason given so far in this thread is that bytecode would be bad for optimization. That's actually the opposite of the truth. A bytecode-like three-address IR would be really convenient for optimization, because it makes the control flow explicit. With the current tree-like IR, the compiler's optimizers have to do some really tricky reasoning about control flow around an expression. Just look at the two examples above. In the first example, control flows from the first statement to the last, one after the other. In the second, control flow hops all over the place, forward and backward. By the way, for Scala in particular, I don't think going through bytecode is the best way. It would be better to work out a new intermediate format that is like Java source, but that does not have the silly restrictions that Java has that GWT does not need. For example, that intermediate format should have an equivalent to multi- expressions (that is, C's or JavaScript's comma operator, or Scala's block expressions). Scala could easily generate it, and GWT could easily take it as input. Such a format might be useful for other projects, too. It would have the flexibility of bytecode while retaining nested expressions. Lex Spoon PS -- I'm not in this group; I was simply pointed at the thread --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
