Programs are often divided into parts that do real work and other parts, called "adapters," which do things like (1) letting code written in different languages to interoperate, (2) managing multiple external data formats, (3) letting servers be reached by disparate clients using multiple middlewares, etc. Adapters are tedious (rather than difficult) to write, and are error-prone and hard to maintain: they are thus good candidates for automation. But, typical adapter-generator tools are limited in scope and tightly bundled with specific middleware solutions. And, programmers might find themselves using many such tools in a complex project, no two of which are similar.
Mockingbird is a uniform tool for generating all kinds of adapters automatically, independent of the particular runtime context in which the adapters will be used. It supports C, C++, Java, and CORBA and can be applied to data conversion, heterogeneous module composition, network interoperation, and other problems. It is also an extensible framework that can encompass new languages and notations with a linear cost to the extender.
The talk gives a snapshot of Mockingbird's present status, built around a live demo. It describes how Mockingbird accomplishes its key objectives and also explores some open problems.
DAP addresses a fundamental problem in client-server and n-tier systems: partitioning distributed object applications -- determining the machine on which each object should be placed and executed for best overall performance of the application. The DAP tool is based on communication dynamics modeled as a graph; it employs multi-way graph cutting algorithms to automatically determine near-optimal object placement; and it incorporates visual feedback to guide programmers in manually refining the partitioning, as well as to guide them in refining the *design* of the application to achieve even greater performance improvements.
Subject-Oriented Programming is a code packaging technology, which makes it possible to, for example:
Montana is an open, extensible integrated programming environment for C++ that supports incremental compilation and linking, a persistent code cache called a CodeStore, and a set of programming interfaces to the CodeStore for tool writers. CodeStore serves as a central source of information for compiling, browsing, and debugging. CodeStore contains information about both the static and dynamic structure of the compiled program. This information spans files, macros, declarations, function bodies, templates and their instantiations, program fragment dependencies, linker relocation information, and debugging information.
Montana allows the compilation process to be extended and modified. Montana has been used as the basis of a number of tools, and is also used as the infrastructure of a production compiler, IBM Visual Age C++ 4.0
This presentation was originally given as a retrospective at the 25th POPL. It reviews the progress of compiler optimization and the ideas and impact of Static Single Assignment form and the algorithms that are used to convert programs to SSA form, analyze SSA form programs and transform SSA based programs to more efficient ones. We also ruminate on the future of the field and where the important problems may lie.
Along with all the hoopla surrounding patterns these days comes more than a little confusion, consternation, and misinformation. Part of the problem rests in how new the field is to mainstream software developers even though it's not, strictly speaking, a new field. It's a fast-moving field, too, creating vacuums of facts. And yes, we pattern proponents deserve some of the blame for not educating people as thoroughly as we'd like, though not for lack of trying. This talk is a humble attempt to dispel the more egregious misconceptions about patterns.
"Patterns" is the latest buzzword from the OO community, but what exactly are they, and how do they help people develop better software? This course introduces the concept and shows how one genre in particular---design patterns---help you build reusable object-oriented software. I cover the roles design patterns play in the object-oriented development process: how they provide a common vocabulary, reduce system complexity, and how they act as reusable architectural elements that contribute to an overall system architecture.
Jinsight is a tool that displays a Java program's behavior at execution. It displays object population, messages, garbage collection, bottlenecks for CPU time and memory, thread interactions, deadlocks, and memory leaks.Jinsight can also take repetitive execution behavior and boil it down to its essentials, eliminating redundancy and uncovering the highlights of an execution. By displaying program behavior and hot spots from several perspectives, Jinsight strengthens your ability to understand, debug, and fine-tune your program. Jinsight works with traces from a modified VM (JDK 1.1.2 or 1.1.5) and visualizes these traces on a 100% Pure Java visualizer.
Jinsight advances the analysis of dynamic, object-oriented (OO) programs in three ways:
In this talk, we describe an efficient algorithm for lazily decomposing aggregates such as records and arrays into simpler components based on the access patterns specific to a given program. This process allows us both to identify implicit aggregate structure not evident from declarative information in the program, and to simplify the representation of declared aggregates when references are made only to a subset of their components. We show that the structure identification process can be exploited to yield the following principal results:
This talk develops a precise characterization of how language features, in isolation and through interaction with one another, generate object and class space requirements for a family of C++ object models. Our characterization has been formalized into what we call a pattern, which can be applied to a class hierarchy graph to generate abstract representations of class tables. This characterization provides a basis for a precise quantitative comparison of the space overhead between these object models. As far as we know, this is the first work to formalize the interaction between C++ language features and quantify its space overhead.
Applying our set of patterns to two benchmarks, we demonstrated that the choice of an object model can have a significant impact on the overall space overhead of object-oriented language features and the impact can vary dramatically between benchmarks: one benchmark's overhead ranges from 35.7% to 125%, and the other benchmark's overhead ranges from 0.42% to 1.62%.
To enhance program optimization, a recent trend in program analysis has been to analyze whole programs, rather than each procedure in isolation. Although this approach can increase precision, it may also increase compilation time. In order for these interprocedural analysis techniques to make the transition from research efforts to production compilers, the cost/precision tradeoffs must be clearly understood.
This talk describes an empirical comparison of four context-insensitive pointer alias analysis algorithms that use varying degrees of flow-sensitivity: a flow-insensitive algorithm that tracks variables whose addresses were taken and stored, a flow-insensitive algorithm that computes a solution for each function, a variant of this algorithm that uses precomputed kill information, and a flow-sensitive algorithm. In addition to contrasting the precision and efficiency of these analyses, we describe implementation techniques and quantify their analysis-time speed-up.
*joint work with Anthony Pioli, Michael Burke, Paul Carini, and Jong-Deok Choi