Network


Latest external collaboration on country level. Dive into details by clicking on the dots.

Hotspot


Dive into the research topics where Clinton L. Jeffery is active.

Publication


Featured researches published by Clinton L. Jeffery.


Electronic Notes in Theoretical Computer Science | 2000

The Alamo Execution Monitor Architecture

Clinton L. Jeffery

Abstract Future programming environments will incorporate a tighter coupling between language runtime systems and the monitoring tools that are used to debug, tune, visualize, and understand them. Many innovations that are developed first in higher level programming language environments will migrate into mainstream languages once their properties are understood and generalized. The Alamo execution monitor architecture was developed to facilitate rapid development of execution monitors, especially visualization tools that are instrumental in understanding complex runtime system interactions in higher level languages. Alamo simplifies the development of such tools by solving the low-level access, control, and intrusion problems inherent in monitoring. Alamo was implemented first for the very high-level imperative goal-directed language Icon. The architecture was then implemented for ANSI C in order to broaden the impact of the work. This paper describes the ANSI C implementation of Alamo and the monitoring services it provides.


acm symposium on applied computing | 2001

Goal-directed object-oriented programming in Unicon

Clinton L. Jeffery

Goal-directed languages offer excellent expressive power for complex algorithms, while object-oriented languages offer outs tanding expressive power for complex da ta structures. The Unicon programming language allows rapid development of complex applications by seamlessly integrating these two paradigms. This paper explores the impact of goatdirected expression evaluation on tradi t ional object-oriented programming style. It is hoped that new programming idioms and techniques will emerge that exploit generators and goal-directed evaluation in an object-oriented setting.


Archive | 1999

An Overview of the Alamo Architecture

Clinton L. Jeffery

This chapter presents an overview of the Alamo architecture and the execution monitoring framework that has been added to the Icon programming language. Alamo stands for A Lightweight Architecture for Monitoring, and describes the overall system design. Each implementation of Alamo is a framework for writing execution monitors using some monitoring language to monitor programs in some target language; typically, the monitoring language and target language are the same. So far, Alamo has been implemented for both the Icon and ANSl C languages [37].


Archive | 1999

A Multitasking Icon Interpreter

Clinton L. Jeffery

This chapter describes MT Icon, a multitasking Icon interpreter that provides key features of Alamo for the Icon language. MT Icon allows multiple Icon programs to be loaded and run simultaneously within a shared address space. Its functionality is general in nature and can be used for purposes other than monitoring. The features of MT Icon are augmented by language facilities that are specific to monitoring; those facilities are described in the next chapter.


Archive | 1999

Monitoring Procedure Activity

Clinton L. Jeffery

Procedure activity is a major aspect of control flow, and it is especially significant in Icon because procedures can generate more than one result. This chapter describes the monitoring of procedure activity in detail. The techniques presented are important because they also apply to the monitoring of Icon’s built-in functions and operators as well as string scanning environments. The examples given are intended to illustrate the framework’s capabilities and are by no means the best or only way in which procedure activity may be portrayed.


Archive | 1999

Monitoring Structure and Variable Usage

Clinton L. Jeffery

Previous chapters have demonstrated techniques for monitoring various aspects of program control and memory usage. Although some aspects of TP data usage are observable by means of memory allocation and garbage collection events, key aspects of program behavior are often characterized in terms of operations on program data, such as manipulations of program data structures or variable references.


Archive | 1999

Following the Locus of Execution

Clinton L. Jeffery

Perhaps the most basic monitoring act is following along in the source-code as execution progresses. Locus of execution information is used in various tools such as source-code viewers and profilers. Frequently, location information is used in combination with other execution information to inform the user of the specific source code line and column responsible for some behavior of interest.


Archive | 1999

Execution Monitoring in MT Icon

Clinton L. Jeffery

MT Icon allows the execution of multiple Icon programs in almost any configuration, including execution monitoring. As motivated in Chapter 4, MT Icon characterizes monitoring as a special case of multitasking execution in which the nature and extent of interprogram communication warrants additional language support. This chapter describes additional MT Icon facilities specifically added to support monitoring. After some relevant definitions, a description of the programming interface and underlying interpreter instrumentation are given.


Archive | 1999

Monitoring Memory Usage

Clinton L. Jeffery

In Icon, memory management is automatic. Memory is allocated when it is needed, and reclaimed implicitly when it is no longer referenced. The memory management subsystem provides significant insight into program behavior. Program performance problems can often be attributed to inefficient memory usage, and the actual pattern of usage can illuminate aspects of behavior ranging from simple transitions between major phases of the program down to semantic errors in program coding.


Archive | 1999

Monitor Coordination and Communication

Clinton L. Jeffery

As illustrated in the preceding chapters, MT Icon and its execution monitoring interface make it easy to develop new EMs. In this model, monitors are free to specialize in particular aspects of program execution, and the user selects the aspects to monitor in a given execution. When multiple EMs come into play, the selection of which EMs to use, the execution of those EMs, and their communication interface are the responsibility of a program called a monitor coordinator (MC).

Collaboration


Dive into the Clinton L. Jeffery's collaboration.

Top Co-Authors

Avatar
Top Co-Authors

Avatar
Researchain Logo
Decentralizing Knowledge