Our examples of inline object allocation focus on Points and Rectangles (see Figure 1); the code in this section will be used in our examples hereafter. To illustrate the complexities involved in automatic inline allocation, we introduce a subclass of Rectangle (Figure 3). We will use the following methods while expounding various aspects of our optimization; significant methods are in Figure 4, and the main program is in Figure 5.
Figure 4 suggests complications of automatic inline allocation that require global program transformations: when the Point::area method is called from Rectangle::area, it must be specialized because, instead of two point objects, it will be called with one rectangle with four inlined fields. Producing this information requires inter-procedural data-flow analysis (Sections 3.2.1 and 4), and exploiting it is a global transformation.
More difficulties arise when inlined objects are put into unrelated containers: we must call appropriate specialized methods when such objects are accessed via the unrelated container. For example, in Figure 5, the compiler must determine that the call to head in do_rectangle returns a Point inlined into a Rectangle so that the appropriate specialized version of abs can be called. This requires data-flow analysis that can flow properties through fields (Section 3.2.1). Our Concert [8] analysis framework is, to our knowledge, the only one that can do this.
The main program (Figure 5) illustrates our other analysis difficulty. Inlining the points involves copying the fields from the constructor arguments into the inlined Point fields within the Rectangle. Such copying would become problematic were do_rectangle to be called with one aliased Point as both arguments, as it would change aliasing relationships. In order to do inline allocation, we must ensure that this has not happened, that is, aliasing relations are not changed so inlining is safe.
In sum, our example illustrates the two challenges we face: 1) finding and specializing uses of inlined objects and 2) ensuring that inline allocation does not change aliasing relationships.
