On Tue, Jun 15, 2010 at 10:11 AM, Thomas Broyer <t.bro...@gmail.com> wrote: > > Well, probably... CodeFlowAnalyzer is a bit too complex for my very > limited knowings of the compiler internals. I'll give it a try though > (but I can't tell you when I'd find time to do it, it's almost all on > my spare time) >
Okay. Just to spell it out a little further, for anyone that finds time, the changes would be like: 1. Add the new set targetsOfNew. 2. Whenever a "new" is visited, add the target class to targetsOfNew. 3. Add a method callable(JMethod) that checks if the method is callable on any of targetsOfNew. 4. Update visit(JMethodCall, Context) and rescueMethodsIfInstantiable to use that method. 5. In Pruner, any target of a JMethodCall that is not live gets turned into an abstract method. It's the same logic in Abstractizer except implemented in a different place. Just so you know, my initial concern was about Protobuf. I'm porting > proto2 to GWT (see http://code.google.com/p/protobuf-gwt/ ), and when > you generate code in optimize_for=SPEED mode, methods of > GeneratedMessage whose default implementation relies on the reflection > API (getDescriptor and the like) are overridden, and actually never > ever called. But in current GWT, the code won't be pruned, which also > includes all Descriptor classes and methods, even if you don't use > them. This could potentially represent a fairly big amount of unused/ > dead code in the output JS. Obviously, when targetting GWT you should > rather use optimize_for=LITE_RUNTIME (which I intend to implement as > JSO overlays in the next iteration), but given that my goal is to > share code between client-side and server-side I'd like to also > support the "non-lite" APIs. > Better protobuf support would certainly be nice! I'll review the patch for if you don't have time to do the ControlFlowAnalyzer version. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
