Smalltalk-80: the language and its implementation
Smalltalk-80: the language and its implementation
A structural view of the Cedar programming environment
ACM Transactions on Programming Languages and Systems (TOPLAS)
MIPS RISC architecture
High-level debugging in parasight
PADD '88 Proceedings of the 1988 ACM SIGPLAN and SIGOPS workshop on Parallel and distributed debugging
Experiences creating a portable cedar
PLDI '89 Proceedings of the ACM SIGPLAN 1989 Conference on Programming language design and implementation
Combining generational and conservative garbage collection: framework and implementations
POPL '90 Proceedings of the 17th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
The art of computer programming, volume 1 (3rd ed.): fundamental algorithms
The art of computer programming, volume 1 (3rd ed.): fundamental algorithms
Java Virtual Machine Specification
Java Virtual Machine Specification
Eighty-Three Eighty-Six Microprocessor Handbook
Eighty-Three Eighty-Six Microprocessor Handbook
A processor for a high-performance personal computer
ISCA '80 Proceedings of the 7th annual symposium on Computer Architecture
Gprof: A call graph execution profiler
SIGPLAN '82 Proceedings of the 1982 SIGPLAN symposium on Compiler construction
The java hotspotTM server compiler
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
Hi-index | 0.00 |
In re-implementing fast breakpoints for stock hardware, I discovered the joys of putting self-modifying code to good use.By "fast breakpoints" I mean inserting transfers of control to change the behavior of a running program. I don't claim to have invented fast breakpoints: I have traced their use back to 1951 [1]. I didn't even put these breakpoints to novel uses. All I did was rediscover how easy it is to take statically compiled code and modify it at runtime to alter the semantics of programs. The most obvious application is to evaluate predicates and expressions for debugging, but other uses are possible.We have designed and implemented a fast breakpoint facility. Breakpoints are usually thought of as a feature of an interactive debugger, in which case the breakpoints need not be particularly fast. In our environment breakpoints are often used for non-interactive information gathering; for example, procedure call count and statement execution count profiling [Swinehart, et al.]. When used non-interactively, breakpoints should be as fast as possible, so as to perturb the execution of the program as little as possible. Even in interactive debuggers, a conditional breakpoint facility would benefit from breakpoints that could transfer to the evaluation of the condition rapidly, and continue expeditiously if the condition were not satisfied. Such conditional breakpoints could be used to check assertions, etc. Program advising could also make use of fast breakpoints [Teitelman]. Examples of advising include tracing, timing, and even animation, all of which should be part of an advanced programming environment.We have ported the Cedar environment from a machine with microcode support for breakpoints [Lampson and Pier] to commercial platforms running C code [Atkinson, et al.]. Most of our ports run under the Unix* operating system, so one choice for implementing breakpoints for Cedar was to use the breakpoint facility provided by that system. The breakpoints provided by the Unix operating system are several orders of magnitude too slow (and also several process switches too complicated) for the applications we have in mind. So we designed a breakpoint system that was fast enough for our purposes.Breakpoints for uni-processors running single threads of control used to be fast and simple to implement. This paper shows that breakpoints can still be fast, even with multiple threads of control on multi-processors. This paper describes problems in the design of a breakpoint package for modern computer architectures and programming styles, and our solutions to them for a particular architecture.