SmartLocalDefs is often recomputed #138
Comments
|
Note: This might not be as easily fixable as I thought. The problem is that the Jimple code is often transformed between subsequent invocations. I guess SSA/Shimple might help here but that would be a quite incompatible change. |
|
Could we checksum the Jimple Body or otherwise ensure that it's not changed? SSA form also imposes a lot of constraints in keeping things up to date; it On Tue, Oct 22, 2013 at 10:24 AM, Eric Bodden notifications@github.comwrote:
|
|
I would vote against SSA since there are many transformers which would have to be rewritten to maintan SSA (which would complicate the code quite a bit) or would have to be followed by a step that re-establishes SSA. In sum, I'm not sure that this would by us anything in terms of performance. |
|
We are hitting this issue as well, and it imposes quite some runtime overhead in our application. Most of the time seems to be spend in the flow analysis according to JProfiler. I saw some recent changes in ForwardFlowAnalysis, did this improve performance? |
|
Yes, we had some performance improvements in the past year, however the main problem still remains: The conversion to Jimple happens in several passes, each pass of which might change (and often does change) the respective JimpleBody. After each of these passes, the SimpleLocalDefs must be recomputed, unless we find a way to incrementally update it, or to maybe perform some checksums as @patricklam suggested. If I find some time I will look into this a bit. |
|
Great. I ported the latest flow analysis code which had a tiny impact on On Sat, Jan 31, 2015 at 2:38 PM, Eric Bodden notifications@github.com
|
…#138 The mechanism works as follows: Clients that previously used to create a new SmartLocalDefs based on a SimpleLiveLocals based on an ExceptionalUnitGraph now instead call a factory method on the new SmartLocalDefsPool. This method either creates a new analysis (along with a new default unit graph), or it returns the one that has previously been created for the same (!) body. To know when body was changed, the pool keeps track of modification counts for bodies. A body was modified when either its locals, units or traps were modified. Luckily, those three chains already keep track of a modification count, which we reuse here. Clients that use SmartLocalDefs over regular ExceptionalUnitGraphs have been updated to use the pool. Some use other UnitGraphs, however, for instance some passes for Android. Those have not been updated.
|
I implemented some pooling in commit 454f7c4 I was unable to update some clients that use DalvikThrowAnalysis. To pool for those, too, we would need to extend the mechanism a bit. |
|
This is awesome! I'll try to backport it to our Soot fork and will report
|
|
Note to self: we should find a way to clear the pool at a sensible time, when Jimplification has completed. |
|
@badlogic You can probably simply cherry-pick the commit via git. |
A simple investigation shows that Soot often recomputes SmartLocalDefs multiple times for the same method (often five times). The analysis is rather costly and should probably be cached instead.
The text was updated successfully, but these errors were encountered: