Given our approach of not (conceptually) destroying the containee, the only fundamental limit on what objects our optimization can inline is the ability to add copies. Adding copies depends upon aliasing information, so is necessarily conservative. For each of the codes, we present four field counts: the total number of fields which hold objects, the number that could ideally be inlined given aliasing constraints (determined by hand), the number of fields declared inline in C++, and the number fields our optimization inlined.
Figure 14: Inlinable Field Counts
Our analysis did as well or better than manual inline allocation on all codes; there was no field manually declared inline in C++ that our analysis did not find inlinable. We did better than C++ on Silo, Richards and polyOver. This is because we inlined a polymorphic field in Richards and merged cons cells with their data in Silo and polyOver.
In both polyOver and Silo, lists present problems. In Silo, our analysis cannot inline cons cells of the global event list, because it cannot tell that a given event is in the list at most once; hence it thinks there is possible aliasing between the data of different elements, so the data and list element cannot be merged. In polyOver, a list cannot be blocked because it is constructed in a loop, and our analysis has no mechanism to distinguish loop iterations.
The Richards code causes another difficulty: an array of pointers to tasks. The array is polymorphic (different elements reference different types of task) and our analysis does not distinguish different array elements, simply representing the array state as an instance variable.