[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
LGTM. Minor: In Pruner, it strikes me that you shouldn't have to do this. Perhaps most of the code in visit(JMethodCall) should be moved into visit(JMethod) BTW: your patch name is teh lolz. :) Scott On Thu, Oct 9, 2008 at 6:25 PM, Lex Spoon [EMAIL PROTECTED] wrote: Thanks, Scott. The patch should apply to trunk. Would you mind it going into trunk if it looks good? I'll merge it over to the runAsync branch the next time I sync it with trunk. The linear search you point at does not look so good on closer inspection. For each method in the program, there is a linear search through all the *entry* methods of the program. That's okay right now, but if there are ever a lot of entry methods, it could get expensive. Attached is an update that is just like the previous one, but it replaces the linear scan by a lookup in an IdentityHashMap. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote: How do you clean up dead refs in the entry method, which isn't part of any class? Good catch. It sounds like there is a more fundamental problem. The runAsync entry methods actually are included in a class. Thus, in some circumstances I saw these methods get cleaned twice and thus ending up with invalid method calls. Since the normal entry method is not part of a class, there's no simple solution for Pruner to do its cleaning up. To make the story consistent, what would you think of attaching the existing entry method to some class? The other arrangement looks awkward, because the runAsync entry methods are the result of generator runs. They're plain old static methods. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
That seems like a reasonable approach.. it was always a bit weird to have a method with no containing class. I'd look at com.google.gwt.lang.ClassLiteralHolder as a template for this idea. In fact, you might be able to get rid of JProgram.entryMethods in favor of an entry class. On Mon, Oct 6, 2008 at 6:53 PM, Lex Spoon [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote: How do you clean up dead refs in the entry method, which isn't part of any class? Good catch. It sounds like there is a more fundamental problem. The runAsync entry methods actually are included in a class. Thus, in some circumstances I saw these methods get cleaned twice and thus ending up with invalid method calls. Since the normal entry method is not part of a class, there's no simple solution for Pruner to do its cleaning up. To make the story consistent, what would you think of attaching the existing entry method to some class? The other arrangement looks awkward, because the runAsync entry methods are the result of generator runs. They're plain old static methods. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
