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.

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.

Lex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to