summaryrefslogtreecommitdiff
path: root/test/2238-checker-polymorphic-recursive-inlining/src/BaseClass.java
AgeCommit message (Collapse)Author
2022-02-15Limit recursive polymorphic inlining to prevent code bloat Santiago Aboy Solanes
If both NoRecursion and Wrapper implement the same method MyMethod, NoRecursion with just `return false` and Wrapper with `return BaseClass.MyMethod()` we would end up with generated code similar to: ``` if (receiver == NoRecursion) { return false; } else if (receiver == Wrapper) { // A polymorphic invoke which turns into: if (unwrappedValue.receiver == NoRecursion) { return false; } else if (unwrappedValue.receiver == Wrapper) { // A polymorphic invoke which turns into // [...] you get the gist, we do this several times. } else { // HInvokeVirtual } } else { // HInvokeVirtual } ``` After the change we would have: ``` if (receiver == NoRecursion) { return false; } else { // HInvokeVirtual } ``` This pattern was worse when there were more than one recursive polymorphic case, increasing exponentially in size. This was common to see on Wrapper classes, but uncommon otherwise. In the two wrappers plus one non-wrapper case in test/2238-, we will now generate a .cfg which is about 6% the size versus before this CL (12M -> 779K). Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b Bug: 217464625 Change-Id: I3c6444193ea2f24af29d97549776a283ef177efd