I've worked on a fair number of debuggers over the years, and in my efforts to engineer new things, I always spend time researching what has gone before. The ACM recently added the ability to unlock papers at their extensive Digital Library, so this gives me the pleasure of beginning to unlock some of the older systems papers that influenced my thinking in various topics over the past decade or so. One of these was The Blit Debugger, originally published in SIGSOFT proceedings, and written by Thomas Cargill of Bell Labs. The Blit itself takes us back quite a ways: it was a bitmapped terminal containing a small microkernel that could communicate with host programs running on UNIX. The idea was that one could write a small C program, which was turned into relocatable form, that could control the bitmap display and the mouse and keyboard, and beam it over to the Blit, where it would be executed by mpx. These mini-programs running in the Blit could then communicate with normal UNIX programs back on the host, i.e. executing in the complete UNIX timesharing environment, to form a complete interactive program. Written in 1983, the same year bytes of 68000 asssembly code were being downloaded over a serial line from a Lisa to early prototype Macs, the Blit quickly looked behind the times only a few months later when MacPaint and MacWrite showed up.
But in computing, everything old is new again, and we don't spend enough time studying our history. Hence we've reinvented virtualization and interpreters about four times now. And looking back at the Blit now, you can kind of squint your eyes and see something quite remarkable. A high-resolution bit-mapped display with keyboard and mouse control, running a kernel of software capable of multiplexing between multiple downloaded graphical applications that can drive user interaction, each communicating over a channel to a more fully capable UNIX machine with complete network access and a larger application logic. Sound familiar? I pretty much just described your favorite web browser, Javascript, and the AJAX programming model. So now on to debugging.
Cargill's Blit Debugger basically let you wander around the Blit display, pointing and clicking to attach the debugger to a program of interest. Then once you did that, it could download the symbol tables to the debugger, and then conjure up appropriate menus on the fly that displayed various program symbols and let you descend data structures. I'll let you read the paper for the full details, but there is a very central concept here, independent of the Blit, that for me turned on a big light bulb when I first read this paper in college. As a programming student, I always considered the debugger a kind of container: i.e. you either ran your program, or you ran it inside the debugger. This was the way we all learned to program, and this was the way all those big all-encompassing IDEs behaved (and mostly still do). The Blit debugger was the first description I'd read of a debugger that was truly a general-purpose tool that could be used to explore any aspect of a running environment, literally allowing its user to wander the screen in search of interesting processes and their symbols that you could shine your flashlight on. And it wasn't a debug environment, it was just your normal, running compute environment.
This is a seminal concept, and one that has had great influence on my work in debugging over the years, most prominently with the development of DTrace, where Bryan and Adam and I created a modern version of this kind of flashlight, one that would let you take your production software environment and roam around arbitrarily asking questions, poking into any aspect of the running system. But looking back at the Blit and its analogies to the rapidly-evolving AJAX environment, I hope that others will find inspiration in this idea as well, and bring new (and old) thinking to what kinds of debugging tools are needed in this environment. Yes, we've got the breakpoint debugger (mostly, it seems to cause my browser to crash) and the DOM inspector (getting better, slowly), but what's really needed is more thought into connecting the browser, the Javascript interpreter, the DOM, and the backend together, in a way that permits interactive on-the-fly exploration. One critical building block for that world now exists, in the form of Brendan's DTrace Support for Javascript. But imagine what would be possible if say, a browser plug-in itself actually leveraged this DTrace support. Suddenly features become possible like "Option-click on a button in an AJAX UI, and I will pop up the stack trace of the HttpRequest that was sent when you did that, and show you the XML-RPC call that was made and its reply." Or "Turn on a profiling mode that shows me what XML-RPC requests spent the most time blocked on the network while I click around the user interface." One can also envision DTrace linkages between the debugger control engine in a browser and a corresponding control engine in the XML-RPC backend that can also use DTrace to instrument itself or the system that contains it.
Meantime, enjoy the paper, and more about the Blit can be found here.
$q
But in computing, everything old is new again, and we don't spend enough time studying our history. Hence we've reinvented virtualization and interpreters about four times now. And looking back at the Blit now, you can kind of squint your eyes and see something quite remarkable. A high-resolution bit-mapped display with keyboard and mouse control, running a kernel of software capable of multiplexing between multiple downloaded graphical applications that can drive user interaction, each communicating over a channel to a more fully capable UNIX machine with complete network access and a larger application logic. Sound familiar? I pretty much just described your favorite web browser, Javascript, and the AJAX programming model. So now on to debugging.
Cargill's Blit Debugger basically let you wander around the Blit display, pointing and clicking to attach the debugger to a program of interest. Then once you did that, it could download the symbol tables to the debugger, and then conjure up appropriate menus on the fly that displayed various program symbols and let you descend data structures. I'll let you read the paper for the full details, but there is a very central concept here, independent of the Blit, that for me turned on a big light bulb when I first read this paper in college. As a programming student, I always considered the debugger a kind of container: i.e. you either ran your program, or you ran it inside the debugger. This was the way we all learned to program, and this was the way all those big all-encompassing IDEs behaved (and mostly still do). The Blit debugger was the first description I'd read of a debugger that was truly a general-purpose tool that could be used to explore any aspect of a running environment, literally allowing its user to wander the screen in search of interesting processes and their symbols that you could shine your flashlight on. And it wasn't a debug environment, it was just your normal, running compute environment.
This is a seminal concept, and one that has had great influence on my work in debugging over the years, most prominently with the development of DTrace, where Bryan and Adam and I created a modern version of this kind of flashlight, one that would let you take your production software environment and roam around arbitrarily asking questions, poking into any aspect of the running system. But looking back at the Blit and its analogies to the rapidly-evolving AJAX environment, I hope that others will find inspiration in this idea as well, and bring new (and old) thinking to what kinds of debugging tools are needed in this environment. Yes, we've got the breakpoint debugger (mostly, it seems to cause my browser to crash) and the DOM inspector (getting better, slowly), but what's really needed is more thought into connecting the browser, the Javascript interpreter, the DOM, and the backend together, in a way that permits interactive on-the-fly exploration. One critical building block for that world now exists, in the form of Brendan's DTrace Support for Javascript. But imagine what would be possible if say, a browser plug-in itself actually leveraged this DTrace support. Suddenly features become possible like "Option-click on a button in an AJAX UI, and I will pop up the stack trace of the HttpRequest that was sent when you did that, and show you the XML-RPC call that was made and its reply." Or "Turn on a profiling mode that shows me what XML-RPC requests spent the most time blocked on the network while I click around the user interface." One can also envision DTrace linkages between the debugger control engine in a browser and a corresponding control engine in the XML-RPC backend that can also use DTrace to instrument itself or the system that contains it.
Meantime, enjoy the paper, and more about the Blit can be found here.
$q