Object and array inlining

 There are other global optimizations possible for object inlining. One uses a cheap interprocedural analysis for object inlining. For example, arrays are only inlined when the length is known and unchanged during compilation. This was implemented in Swift which is a flavor of Java compiler for Alpha architecture.

Another approach modifies the object copying order of the garbage collector which improves the cache performance but it has little or no effect on field loads. Another approach, known as the online object reordering, optimizes all the fields accessed frequently. Another approach, known as the cache conscious data placement, uses run-time counters but does not distinguish between different fields of the same object.  A pointer-analysis approach has an algorithm that guesses the possible run-time values of pointers but this one is unsuitable for object and array inlining because it works only with the location a variable may point to. But such location information is valuable when it is precise and so there is another approach that collects the points-to-mapping for all instances. This can be useful to flatten multi-dimensional arrays.

Array inlining is not possible without a global data flow analysis because it can only optimize array fields.

A summary of the above discussion now follows.  Object and array inlining can significantly tune up the performance of a Java application. Array inlining is explored more in this discussion as compared to related work on both Object and Array fields. There are three types of inlining: fixed array inlining, variable array inlining, and dynamic array inlining. Fixed array inlining is one where the array fields can be handled the same way as object fields because the length is constant. Variable array inlining is one where the array fields have different but fixed lengths. Dynamic array inlining is one where the array field is assigned multiple times. The inlining works when the following two conditions are met. First, the parent and child objects must be allocated together and the field store that places the reference of the parent in the child must happen immediately afterwards so that it remains true for the lifetime of the data structures that are collocated this way. Second, the field stores must not overwrite the field with a new value. The inlining saves one instruction at a time which is the load of the inlined field. The tradeoff between the benefits of inlining or not is demonstrated by the length of the time interval between the overwrite of the fields and the garbage collection which restores the optimized field order.  The garbage collector is based on aging and compaction of heap allocations. The younger generation is collected frequently since they are not used on a prolonged basis.  The stop-and-copy collector copies young objects between two alternating spaces and it increments a field for age in each activity. Objects and array inlining are made on a field by field basis at run time. The analysis overhead has to be small and the speedup has to be big so that the optimization is worth it. Among the approaches in such analysis, a statistic that places this in context of the global total of all the fields in all loaded classes makes the criterion clearer than just local analysis.