Debugging and analyzing a snapshot of a crashed program's memory is far more difficult than working with a live program, because debuggers can no longer execute code to help make sense of the program state. We present an architecture that supports the restricted execution of ordinary code starting from the snapshot, as if the dead objects within it had been restored, but without access to their original external environment. We demonstrate the feasibility of this approach via an implementation for Java that does not require a custom virtual machine, show that it performs competitively with live execution, and use it to diagnose an unresolved memory leak in a mature mainstream application.

The adoption of programming language innovation is impeded because all program processing tools in the tool chain must support any new or altered language features. Registration-based abstractions (RBAs) were proposed to address this difficulty by allowing the editor to transiently superimpose new language abstractions on existing code. Individual programmers can choose where and when to see a new language abstraction, while at all times the underlying code remains written in the original language. Prior work demonstrated the feasibility of RBAs, but left important questions unanswered regarding how users would interact with such an approach. We asked 50 undergraduate students to answer basic program comprehension questions with and without RBAs. Our results show that participants can quickly and easily understand new abstractions without additional training, and suggest that this will extend to the general programmer community. The results also support a comparison across RBAs, and an initial discussion of specific features that facilitate or confound understanding.

Programming language innovation has been hindered by the difficulty of making changes to existing languages. A key source of difficulty is the tyrannical nature of existing approaches to realizing languages -- adding a new language construct means that any tool, document or programmer that works with the language must be prepared to deal with that construct.A registration-based approach makes it possible to define language constructs that are not tyrannical. They are instead transient -- the program appears to be written using the constructs only so long as a given programmer wants to see it that way. This approach may have the potential to greatly facilitate programming language innovation.

Summary form only given. The idea that programs should clearly reflect the design decisions they embody has a long history. Higher-level languages, syntactic macros, domain-specific languages, and intentional programming are different approaches to this common goal. Recent work from several areas, including aspect-oriented programming, has significantly advanced our ability to make code expressive. At the same time, it forces us to reconsider a number of basic assumptions, including what is a program, what is a module, what is a language, and what is an editor.

No abstract available

Aspects cut new interfaces through the primary decomposition of a system. This implies that in the presence of aspects, the complete interface of a module can only be determined once the complete configuration of modules in the system is known. While this may seem anti-modular, it is an inherent property of crosscutting concerns, and using aspect-oriented programming enables modular reasoning in the presence of such concerns.

A characteristic of aspect-oriented programming, as embodied in Aspect J, is the use of advice and point cuts to define behavior that crosscuts the structure of the rest of the code. The events during execution at which advice may execute are called join points . A pointcut is a set of join points. An advice is an action to be taken at the join points in a particular pointcut. In this model of aspect-oriented programming, join points are dynamic in that they refer to events during the flow of execution of the program.We give a denotational semantics for a minilanguage that embodies the key features of dynamic join points, pointcuts, and advice. This is the first semantics for aspect-oriented programming that handles dynamic join points and recursive procedures. It is intended as a baseline semantics against which future correctness results may be measured.

AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements are manifested in terms of better code locality, reusability, composability, and (un)pluggability.The degree of improvement in implementation modularity varies, with the greatest improvement coming when the pattern solution structure involves crosscutting of some form, including one object playing multiple roles, many objects playing one role, or an object playing roles in multiple pattern instances.

Operating system structure is important; it leads to understandable, maintainable, 'pluggable' code. But despite our best efforts, some system elements have been difficult to structure. We propose a new analysis of this problem, and a new technology that can structure these elements. Aspect-oriented programming (AOP) (G. Kiczales et al., 1997) uses linguistic mechanisms to support the separation of crosscutting elements, or aspects of the system, from primary functionality. We have developed a proof-of-concept AOP implementation of prefetching in FreeBSD (www.cs.ubc.ca/labs/spl/aspects/aspectc.html). In our implementation, we have been able to modularize prefetching.

Layered architecture in operating system code is often compromised by execution path-specific customizations such as prefetching, page replacement and scheduling strategies. Pathspecific customizations are difficult to modularize in a layered architecture because they involve dynamic context passing and layer violations. Effectively they are vertically integrated slices through the layers. An initial experiment using an aspect-oriented programming language to refactor prefetching in the FreeBSD operating system kernel shows significant benefits, including easy (un)pluggability of prefetching modes, independent development of prefetching modes, and overall improved comprehensibility. Keywords aspect-oriented programming, software modularity, operating system design 1.

Aspect-oriented programming (AOP) is a technique for improving separation of concerns in software design and implementation. AOP works by providing explicit mechanisms for capturing the structure of crosscutting concerns. This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way. It works with AspectJ, a seamless aspect-oriented extension to the Java(tm) programming language, and with AspectC, an aspect-oriented extension to C in the style of AspectJ. It also includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.

Using only traditional techniques the implementation of concerns like exception handling, multi-object protocols, synchronization constraints, and security policies tends to be spread out in the code. The lack of modularity for these concerns makes them more difficult to develop and maintain. This tutorial shows how to use Aspect-oriented programming (AOP) [2, 3] to implement concerns like these in a concise modular way. We discuss the effect aspects have on software design and on code modularity. The concrete examples in the tutorial use AspectJ [1], a freely available aspect-oriented extension to the Java™ programming language.

Designing reusable software modules can be extremely difficult.The design must be balanced between being general enough to address the needs of a wide range of clients and being focused enough to truly satisfy the requirements of each specific client One area where it can be particularly difficult to strike this balance is in the implementation strategy of the module.The problem is that generalpurpose implementation strategies, tuned for a wide range of clients, aren't necessarily optimal for each specific client-this is especially an issue for modules that are intended to be reusable and yet provide high-performance.An examination of existing software systems shows that an increasingly important technique for handling this problem is to design the module's interface in such a way that the client can assist or participate in the selection of the module's implementation strategy.We call this approach open implementation.When designing the interface to a module that allows its clients some control over its implementation strategy, it is important to retain, as much as possible, the advantages of traditional closed implementation modules.This paper explores issues in the design of interfaces to open implementation modules.We identify key design choices, and present guidelines for deciding which choices are likely to work best in particular situations.

Over the past years, the Object Technology community has seen the birth of a number of new technology ideas that have changed the way we do computing. These ideas have affected compiler design, analysis approaches, project management techniques, user interface design, deployment strategies and implementation tactics. But where do these ideas come from? And how do they evolve? Do they address the needs as specified by members of the Object Community? Is there a way we can nurture the introduction and assimilation of these ideas to and by the community at large? And what are the market forces that bend ideas to their will. This panel will look at new ideas in Object Technology from a variety of perspectives and will attempt to get to the heart of the way that we, as technologists, create, buy, sell and grow ideas.

No abstract available.

The design and specification of an extensible class library presents a difficult challenge:because extensibility comes from allowing the user to override parts of the implementation, more of the internal structure must be exposed to the user than in a typical procedure library.This raises issues in both how the library is designed and how its specification is written.Specification of the CLOS Metaobject Protocol required a combination of new and existing techniques to address these issues.We present those techniques, and discuss their relation to the underlying issues."This CLOS-like syntax indicates that draw is a one argument generic function; that the argument is called button; and that this method is specialized to the class text-button.