tree 856dc90094289e41f119abb160b5a00a50d36b48
parent 3726e35942658a60e9e9549dc95d62590c9eade7
author Mathias Rav <mathiasr@google.com> 1527148481 +0200
committer Mathias Rav <mathiasr@google.com> 1527148481 +0200

Outliner: Don't use mutable keys in HashMap

The Outline type (used by Outliner to represent outlining candidates)
is mutable since it stores references to IR instructions belonging to
particular methods. As a result, the Outline type can change its mapping
identity when R8 optimizations determine that an instruction's out-value
can be set to null (which happens e.g. on all StringBuilder and
StringBuffer methods that are known to return `this`). When Outline is
used as the key type in a HashMap, the map must not stay around long
enough for the Outline keys to change their mapping identities in this
way. Change Outliner from keeping a Map<Outline, List<DexEncodedMethod>>
as its outlining candidates to simply List<List<DexEncodedMethod>>, one
method list per Outline.

The Outliner should not assume that when converting IRCode x to CF/DEX
and back to an IRCode y, the set of outlines spotted in x is equal to
the set of outlines spotted in y. Instead, outlining should be performed
in three phases: First, when all methods are converted to IR as part of
normal processing, outlines are spotted to identify methods containing
frequently-occurring outline sites. Second, the identified methods are
converted back to IR to identify the actually-frequent outlines.
Third, the outline support class is generated and the actually-frequent
outlines are outlined. Note that the IR constructed in the second step
is thrown away in order to ensure that the same set of outlines are
spotted in the second and third steps.

Change-Id: I665b041a04d3c7fee392c3a0a3b5cccb093d9cad