INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE Specialization Patterns Ulrik Pagh Schultz, Julia L. Lawall, and Charles Consel N˚3853 Janvier 1999 THÈME 2 apport de recherche ISSN 0249-6399 ISRN INRIA/RR--3853--FR+ENG Sp ecialization Patterns Ulrik Pagh Schultz, Julia L. Lawall, and Charles Consel Thème 2 Génie logiciel et calcul symb olique Pro jet COMPOSE Rapp ort de recherche n3853 Janvier 1999 28 pages Abstract: Design patterns oer numerous advantages for software development, but can intro duce ineciency into the nished program. Program sp ecialization can eliminate such overheads, but is most eective when targeted by the user to sp ecic b ottlenecks. Con- sequently, we prop ose to consider program sp ecialization and design patterns as comple- mentary concepts. On the one hand, program sp ecialization can optimize ob ject-oriented programs written using design patterns. On the other hand, design patterns provide infor- mation ab out the program structure that can guide sp ecialization. Concretely,we prop ose specialization patterns, which describ e how to apply program sp ecialization to optimize uses of design patterns. In this pap er, we analyze the sp ecialization opp ortunities provided by sp ecic uses of design patterns. Based on the analysis of each design pattern, we dene the asso ciated sp ecialization pattern. These sp ecialization opp ortunities can b e declared straightforwardly using the sp ecialization classes framework, develop ed in earlier work. Our exp eriments show that such sp ecialization leads to signicant p erformance improvements. Key-words: design patterns, program sp ecialization, ob ject-oriented programming, Java, optimization Résumé : tsvp Supp orted in part by BULL, and in part by Alcatel under the Reutel 2000 contract. Unité de recherche INRIA Rennes IRISA, Campus universitaire de Beaulieu, 35042 RENNES Cedex (France) Téléphone : 02 99 84 71 00 - International : +33 2 99 84 71 00 Télécopie : 02 99 84 71 71 - International : +33 2 99 84 71 71 Schémas de sp écialisation Résumé : Les schémas de conception sont reconnus p our faciliter le développ ement de programmes à ob jets. Cep endant, ils intro duisent souvent une certaine inecacité au sein du logiciel nal. La sp écialisation de programmes est une technique particulièrement adaptée à l'optimisation des programmes à ob jets. Toutefois, l'utilisation ecace de la sp écialisation sur des logiciels de grande taille requiert une connaissance détaillée des goulots d'étranglement de la part du programmeur. Dans cet article, nous prop osons d'asso cier sp écialisation de programmes et schémas de conception. Notre prop os est double. D'une part, la sp écialisation p ermet de supprimer les inecacités intro duites par les schémas de conception. D'autre part, les schémas de concep- tion fournissent des informations sur la structure du programme qui p ermettent de guider le pro cessus de sp écialisation. Plus précisément, nous intro duisons la notion de schémas de spécialisation an de mémoriser comment la sp écialisation de programmes p eut optimiser l'utilisation d'un schéma de conception. Nous démontrons l'applicabilité des schémas de sp écialisation, en caractérisant les opp ortunités de sp écialisation présentes dans plusieurs schémas de conception. Nous intro duisons notre appro che en présentant des exemples de programmes sp écialisés automatiquementaumoyen des schémas de sp écialisation. Mots-clé : schémas de conception, sp écialization de programmes, programmation orientée ob ject, Java, optimisation Specialization Patterns 3 1 Intro duction Design patterns, as presented by Gamma et al. [16], describ e well-tested program structures that enhance mo dularity and co de reuse. A program written using design patterns is struc- tured into indep endent units that interact through generic interfaces, and that evolveover time in resp onse to changing conditions. Because design patterns are well-do cumented, their use simplies the understanding of programs constructed from many indep endent units. The exibility inherent in this use of generic interfaces, however, intrinsically blo cks optimiza- tion across ob jects, and thus can carry a signicant p erformance p enalty. This issue remains largely unaddressed in the design pattern community. Many applications do not fully exploit the exibility oered by design patterns. For a simple example, consider a typical use of the iterator design pattern [16], which sepa- rates traversal of a data structure from its representation. Using the iterator pattern, an implementation of a Set data structure might dene the member metho d as follows: public class Set { MinimalCollection coll; // underlying collection public boolean member Object o { Iterator e = coll.iterator; // obtain iterator while e.hasNext { // while iterator has elements Object x = e.next ; // obtain next iterator element if x.equals o return true; } return false; } ... } This denition of the member metho d can b e used with any underlying MinimalCollection implementation, letting the programmer freely cho ose the most appropriate concrete rep- resentation for the task at hand. Nevertheless, our exp eriments show that the use of the iterator pattern blo cks compiler optimization of the element retrieval op erations. When the member metho d is used rep eatedly to search MinimalCollection ob jects that have the same representation, the exibility provided by accessing the data through an abstract interface is not needed. In this case, the member metho d can b e optimized, by replacing the generic uses of the iterator pattern underlined in the metho d denition by direct accesses to the 1 underlying data structure. This transformation gives a sp eedup ranging from 20 to 80. These measurements suggest that the optimizations p erformed by state-of-the-art compilers do not completely comp ensate for the genericityintro duced by design patterns. When the data representation is invariantover a p erio d of time, sp ecializing the program to this representation b efore execution improves eciency. However, manual sp ecialization is error-prone, and intro duces excessive program-maintenance overhead. Recently, automatic program sp ecialization has b een shown to be eective in the context of ob ject-oriented 1 Exp eriments done with JDK 1.2.1 JIT and HotSp ot compilers on SPARC architecture, with array and linked list representations of the underlying MinimalCollection data structure. RR n3853 4 Ulrik Pagh Schultz, Julia L. Lawal l, and Charles Consel languages, sp ecically Java [22,28]. Automatic program sp ecialization systematically elimi- nates b oth algorithmic and structural overheads, and consequently can signicantly improve p erformance. For example, program sp ecialization has b een shown to b e eective for elimi- nating overheads intro duced by software architectures [24]. Nevertheless, sp ecialization is not always b enecial; for example sp ecializing with resp ect to to o many dierent representations can cause co de explosion. Therefore, the user must explicitly target the sp ecializer toward particular invariants and regions of co de. The spe- cialization classes framework prop osed byVolanschi et al. [32] provides a simple and declar- ative notation for expressing such sp ecialization opp ortunities. Nevertheless, the problem of identifying sp ecialization opp ortunities remains. Proling can help, however, it may not reveal systematic structural overheads that blo ck optimization throughout the program. A systematic approach taking into account the program design is needed. This pap er We observe that the use of design patterns in a program gives rise to patterns of structural prop erties, which in turn give rise to patterns of overheads. These patterns of overheads form patterns of opp ortunities for sp ecialization. We prop ose the use of specialization patterns as a complement to design patterns, to describ e when, how, and why a program structured using design patterns can b enet from sp ecialization. This approach retains the program structuring advantages of design patterns, while relying on an automated transformation to map generic co de into an ecient implementation. The contributions of this pap er are as follows: We address the muchoverlo oked problem of p erformance of programs written using design patterns, by analyzing the overheads systematically intro duced by the use of design patterns. We describ e how to systematically apply program sp ecialization to eliminate these overheads, automatically mapping well-structured generic implementations into mono- lithic ecient ones. We dene sp ecialization patterns for three well-known design patterns: the builder pattern, the bridge pattern, and the strategy pattern. We provide several examples of how sp ecialization can optimize uses of design patterns, and provide b enchmarks showing the eect of sp ecialization on realistic versions of these examples. Earlier work has addressed the declaration of what to sp ecialize in the form of sp ecialization classes [32] and how to sp ecialize in the form of a prototyp e Java sp ecializer [28]. Here, we address the key issue of selecting where to sp ecialize. First, Section 2 describ es our p ersp ective on design patterns, followed by Section 3, which explains program sp ecialization. Section 4 describ es sp ecialization of design patterns by means of sp ecialization patterns. Afterwards, Section 5 provides a substantial example, INRIA Specialization Patterns 5 combining several design patterns. Then, Section 6 assesses