On Jun 14, 10:05 pm, Lex Spoon <[email protected]> wrote: > It's a fun idea! Methods that are only there for their type signatures could > have their bodies removed. > > Ideally, ControlFlowAnalyzer would be able to identify such methods, and > Pruner would remove their bodies. With that arrangement, the CFA and the > method abstracting would mutually benefit each other. It would also lead to > better code splitting. > > ControlFlowAnalyzer already has a notion of "instantiable types". I believe > it needs to be improved, though, to be effective at abstracting methods. To > test that theory, set a break point in Pruner.execImpl right before it calls > setInstantiableTypes. At that point, the question is whether the > abstractable methods are marked as being called or not. I believe they will > be marked as callable.
"instantiatedTypes" contains both interfaces and abstract classes (same for "referencedTypes"). > To improve that, a new set could be added to hold the classes that are > targets of "new". Then, when ControlFlowAnalyzer visits a virtual method > call, it would have the information it needs to skip over the abstractable > methods. > > I am still mulling over the general idea, but that's my initial reaction. If > push comes to shove, we could certainly add another whole-tree walk like in > this patch, and it would be an improvement. It would make a bigger > improvement, though, if we can factor it into an existing optimization. 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) 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. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
