Lecture Notes for CS 404/504 Program Monitoring and Visualization

By the 1980's interactive 2D graphics was ubiquitous and improving rapidly in performance. People started to use graphics to help understand program execution behavior partly because text-only techniques did not scale well, and partly juse because the graphics was available. A movie called "Sorting out Sorting" (parts 1,2,3), originally presented at SIGGRAPH, made a compelling argument that graphical techniques could be valuable in teaching and understanding algorithms.

Sorting Out Sorting was done one frame at a time on truly ancient facilities. A group at Brown University (home of graphics guru Andy Van Dam, algorithms guru Robert Sedgewick and a cast of thousands) set out to replicate on interactive workstations what Ron Baecker had done a frame at a time. One result of this effort was Marc Brown's Ph.D. and related software. We will present more history in a later session.

What About Us?

About Unicon

Monitoring Framework Intro

Graphic Design of the Day: a map

lecture 3

Graphic Design of the Day: Line Plots

Look at HW#1 submissions

Writing your first Unicon monitor

Homework #2

lecture 4

Summary Notes from HW#1

• solutions ranged from 138-335 lines. longer is not better. Writing good Unicon is like haiku or other short poetry. Practice toward mastery of the art. Don't settle for odd-syntax-Java.
• avoid platform-dependent colors - stick to the portable color names (see icon Graphics Book) or use RGB's.
• avoid platform-dependent fonts - stick to mono, sans, serif, typewriter
• do not assume that the display is larger than 1024x768
• put your name in a header comment at the top of your homework
• check user input for validity, avoid crashes

Unicon Language Topic: Surprised by Failure?

When to check for failure: everywhere that failure can occur, and everywhere that failure will matter. Examples:

• comparisons are designed to fail, most folks don't miss these
• type conversions like integer() are also designed to fail
• open() and similar system functions that ask for an operating system resource that might not be available -- check them!
• find() and similar built-ins, UNLESS you can prove data is valid
• subscripts, unless you can prove valid index ranges

lecture 5

Graphic Design of the Day

HW#1, clean co-expressions sample solution

Visualization Principles (book section 3.1.2)

animation

incremental algorithms are a primary means of achieving efficient animation. instead of minimizing ink, this is like minimizing the motion of the plotter arm, or in our case, the # of memory writes.

least astonishment

use the golden rectangle, labels and legends

metaphors

use a familiar metaphor

interconnection

connecting different pieces of data is key, follow Playfair's example

interaction

the big difference between a visualization and a paper chart or graph is that the user can interact with the data. exploit this.

dynamic scale

visualizations compete for screen space and hardware varies widely. it is extra work, but if you write everything so that it scales, your visualization will be useful on more machines and in more ways.

static backdrop

one of the best ways to make dynamic data understandable is to present it in terms of static data. An execution is an instance of the underlying universal abstract thing that is the program.

lecture 6

HW#2 Results

Notes on HW#2 Code

overall, submissions were fantastic

main(av)

av is always a list of strings; if no arguments, *av = 0

paramnames() is a generator

use it with every, or ask questions like "if type(x:=paramnames(...))=="list" then..."

consider the virtues of the apply operator p ! L

consider the virtues of every maxval <:= !L

isn't max() a built-in function at this point? maxval := (max ! L)

failure and success

say "if i := find() then ...", not: "i := find(); if \i then ..."

check for open() failure

I asked nicely before, now I am telling you

sticking &fail at the end of a routine is a noop

a routine fails if it falls off its end; &fail does not return a failure. Unlike lisp, the return value of a function is not its final expression's evaluation.

some folks used the structure() function

please be nice and tell folks how it was useful here

Graphic Design of the Day

Monitoring Feature of the Day

lecture 7

Announcement

Suspects, Tools, and Big Programs

Suspects

This directory was compiled by Ralph Griswold as a collection of interesting or weird programs whose behavior could be understood by program visualization. The good part of the Suspects directory is that the programs all run non-interactively, in some cases they were modified to do so, and those that require input have sample .dat files on which they run nicely. This lets monitors do their thing unimpeded. We should probably add some representative object-oriented programs to this collection this semester. I probably can dig out my "gui recorder" and create recordings of GUI programs so that we can monitor them conveniently in this context.

tools

This directory was compiled by Clinton Jeffery as a collection of simple program visualization programs and library procedures. Many of these codes are featured in the book, Program Monitoring and Visualization.

Big Programs

The largest programs in the suspects directory are typeinfer (2.6k lines), and yhcheng (1.9k lines). These were considered large in the Icon language, where source codes are typically 1/3 to 1/10 the size of C programs that do the same thing. The other largest public domain Icon programs are in the ipl/*packs directories. Among these, ibpag2 is 3.7k lines, itweak is 3.5k lines, skeem is 3.1k lines, ged is 3.6k lines, htetris is 4.3k lines, vib is 4.4k lines, and weaving is 11.3k lines (?). Monitoring these might or might not be easy, since they may be interactive, and you might or might not know what to click at them in order to get them to behave. The largest known Icon programs (source not available) was Bill Wulf's testcase generator (rumored to be on the order of a half-million lines, perhaps machine-generated.

In the Unicon language, programs are far larger on average. The unicon translator itself is 10k lines of Unicon. The uni/lib class library is 20K lines, and the uni/gui GUI class library is 14.5K lines; large subsets of these libraries may be added onto whatever the tool size is. The Unicon IDE is 17K lines, the IVIB user interface builder is 16K lines, and so on. Some of these you can acually monitor.

The largest Icon/Unicon programs for which I have source code include the SSEUS database review/update system (35K lines), and a Knowledge Representation language and system (50K lines) done by an AT&T scientist. It might be possible to find these and monitor them, but it would take work to set them up for monitoring.

Unicon feature of the day: Packages

   static type
   initial type := proc("type", 0)	# protect attractive name

So anyhow, Robert Parlett implemented packages, and I accepted them, and now they are here to stay, and they aren't bad. You do have to know the "package" and "import" keywords, and the ::foo syntax, and that is about it.

MiniLoc

HW#3

lecture 8

Hani's Clever Case Tag

  if x === firstbranchexpr then firstcodebody
  else if x === secondbranchexpr then firstcodebody
  else if x === thirdbranchexpr then firstcodebody
  ...

You can add a predicate filter on the front, or have your values supplied from subroutines, or whatever:

   case x of {
   p() & q() & foo: { ... }
   a | b | 1 to 10 | f(): { ... }
   }

This afternoon we are about to see examples that use this generator capability with cset event masks, as in the following, but it would work with sets, table keys, or any other generator you wanted to write.

case x of {
   ...
   !ProcMask: {
      }
   ...
   }

Hani showed me some code this afternoon that looked like

case x of {
   ...
   member(a_set, x): {
      }
   ...
   }

Monitoring Procedure Activity

Monitoring Icon and Unicon is a little more complicated because procedures can suspend and be resumed. The events for this behavior are E_Pcall, E_Psusp, E_Presum, E_Pret, E_Pfail, E_Prem. The "call stack" becomes a "call tree", or as section 8.1 in the text calls it, an activation tree (a better term since procedures can be activated by more than just calls).

You can just ask for all the procedure activity events, but if your monitor is doing more than just counting them then it potentially will need to do more. One way to monitor the activation tree is to build a model of the tree itself. You can do this by hand, or your monitor can use a library procedure named evaltree() which does it for you. (Study in detail the implementation of evaltree on p88-89). We will look at examples that use evaltree, but first a word on timing.

The time cost of monitoring

Example. In the Suspects/ directory are many candidates (which one runs the longest?). We will consider the poetry scrambler for this example.

time ./scramble <scramble.dat

1.0u 0.0s 0:03 32% 0+0k 0+0io 0pf+0w

Now I take an almost-empty monitor, timer.icn, and time it using the UNIX utility.

time timer ./scramble <scramble.dat

tp time: 1830-0=1830
em time: 0-0=0
1.0u 0.0s 0:03 30% 0+0k 0+0io 0pf+0w

One problem with measurement is that accuracy is limited by tools of observation and hardware/OS limitations. Another problem with measurement is that external evironmental considerations (load average, user activity) change results to some extent. These measurements were done on mars.cs.uidaho.edu, a sparc Solaris machine. The "who" command reported 5 different people logged in at the time, although the load average was apparently low (inactive terminal sessions).

Now, suppose Ziad says monitoring the evaltree is slow. Why might that be?

• procedure activity events are frequent. Not as frequent as line number changes... or are they more frequent?
• each procedure activity event costs two co-expression switches
• each procedure activity event costs however much execution time evaltree itself requires...

Compare evaltime.icn, evaltime2.icn, evaltime3.icn, showing an attempt to do this experiment.

time evaltime ./scramble <scramble.dat

tp time: 2760--10=2770
em time: 6670-0=6670
10.0u 0.0s 0:18 55% 0+0k 0+0io 0pf+0w

tp time: 2490-0=2490
em time: 2660-0=2660
5.0u 0.0s 0:08 61% 0+0k 0+0io 0pf+0w

tp time: 2580-0=2580
em time: 2050-0=2050
5.0u 0.0s 0:07 70% 0+0k 0+0io 0pf+0w

Many Morals of the story:

• the UNIX time(1) command is not very fine-grained or precise.
• The monitoring of &time gives times in milliseconds which might or might not be reliable, they report what the C millisec() function returns.
• The monitoring facilities attempt to explicitly separate the &time reported by the TP from that of the EM.
• The coding of the EM has a (surprisingly?) large impact on the practicality of the EM. Mastering the language and coding elegantly actually matters for EM authors.
• Co-expression switch time may dominate but not totally dominate timings. Griswold was fond of saying that on at least one old CPU where it was measured, the co-expression switch cost less than a procedure call in Icon. This is probably not true for us, but co-expression costs are not the only factor in performance and not always the primary factor.
• The evaltree.icn module might be rewritable for much better speed.
• Icon and Unicon VM compilers need a decent case expression optimization. iconc might already do one, I am not sure.

scat

$include "evdefs.icn"
link evinit
link evaltree
link scatlib

global	at,   # table: sets of procedures at various locations
	call, # table: call counts
	rslt, # table: result counts
        red,
        green,
        black

record activation (node, parent, children)

procedure main(av)
   local mask, current_proc, L, max, i, k, child, e

   EvInit(av) | stop("can't monitor")

   scat_init()
   red := Clone(&window, "fg=red")
   green := Clone(&window, "fg=green")
   black := Clone(&window, "fg=black")

   current_proc := activation(,activation(,,,,[]),[])

   evaltree(ProcMask ++ FncMask ++ E_MXevent,
	    scat_callback, activation)

   WAttrib("label=scat (finished)")
   EvTerm(&window)
end

procedure scat_callback(new, old)
   case &eventcode of {
      E_Pcall:
	 scat_plot(new.node, 1, 0, , colorfor)
      E_Psusp | E_Pret:
	 scat_plot(old.node, 0, 1, , colorfor)
      E_Fcall:
	 scat_plot(new.node, 1, 0, , colorfor)
      E_Fsusp | E_Fret:
	 scat_plot(old.node, 0, 1, , colorfor)
      E_MXevent: {
         case &eventvalue of {
	    "q" | "\033": stop("terminated")
	    &lpress : {
	       repeat {
	          scat_click(proced_name)
		  if Event() === &lrelease then
		     break
		  }
	       }
	    }
	 }
      }
end

procedure proced_name(p)
   return image(p) ? {
      [ =("procedure "|"function "), tab(0) ]
      }
  stop(image(p), " is not a procedure")
end

procedure colorofone(p)
  return if match("procedure ", image(p))
	 then red else green
end

procedure colorfor(L)
   if *L = 0 then return &window
   every x := !L do {
      if not (/c := colorofone(x)) then
	 if colorofone(x) ~=== c then
	    return black
      }
   return c
end

What is scat good for?

algae

   EvInit(av) | stop("Can't EvInit ",av[1])
   codes := algae_init(algaeoptions)
   evaltree(codes, algae_callback, algae_activation)
   WAttrib("windowlabel=Algae: finished")
   EvTerm(&window)

procedure algae_init(algaeoptions)
   local t, position, geo, codes, i, cb, coord, e, s, x, y, m, row, column
   t := options(algaeoptions,
	   winoptions() || "P:-S+-geo:-square!-func!-scan!-op!-noproc!-step!")
   /t["L"] := "Algae"
   /t["B"] := "cyan"
   scale := \t["S"] | 12
   delete(t, "S")
   if \t["square"] then {
      spot := square_spot
      mouse := square_mouse
      }
   else {
      scale /:= 4
      spot := hex_spot
      mouse := hex_mouse
      }
   codes := cset(E_MXevent)
   if /t["noproc"] then codes ++:= ProcMask
   if \t["scan"]   then codes ++:= ScanMask
   if \t["func"]   then codes ++:= FncMask
   if \t["op"]     then codes ++:= OperMask
   if \t["step"]   then step := 1
   hotspots := table()
   &window := Visualization := optwindow(t) | stop("no window")
   numrows := (WHeight() / (scale * 4))
   numcols := (WWidth() / (scale * 4))
   wHexOutline := Color("white") # used by the hexagon library
   if /t["square"] then starthex(Color("black"))
   return codes
end

procedure algae_callback(new, old)
   local coord, e
   initial {
      old.row := old.parent.row := 0; old.column := old.parent.column := 1
      }
   case &eventcode of {
      !CallCodes: {
	 new.column := (old.children[-2].column + 1 | computeCol(old)) | stop("eh?")
	 new.row := old.row + 1
	 new.color := Color(&eventcode)
	 spot(\old.color, old.row, old.column)
	 }
      !ReturnCodes |
      !FailCodes: spot(Color("light blue"), old.row, old.column)
      !SuspendCodes |
      !ResumeCodes: spot(old.color, old.row, old.column)
      !RemoveCodes: {
	 spot(Color("black"), old.row, old.column)
	 WFlush(Color("black"))
	 delay(100)
	 spot(Color("light blue"), old.row, old.column)
	 }
      E_MXevent: do1event(&eventvalue, new)
      }
   spot(Color("yellow"), new.row, new.column)
   coord := location(new.column, new.row)
   if \step | (\breadthbound <= new.column) | (\depthbound <= new.row) |
      \ hotspots[coord] then {
      step := &null
      WAttrib("windowlabel=Algae stopped: (s)tep (c)ont ( )clear ")
      while e := Event() do
	 if do1event(e, new) then break
      WAttrib("windowlabel=Algae")
      if \ hotspots[coord] then spot(Color("light blue"), new.row, new.column)
      }
end

procedure square_spot(w, row, column)
   FillRectangle(w, (column - 1) * scale, (row - 1) * scale, scale, scale)
end

# encode a location value (base 1) for a given x and y pixel
procedure square_mouse(y, x)
   return location(x / scale + 1, y / scale + 1)
end

#
# setspot() sets a breakpoint at (x,y) and marks it orange
#
procedure setspot(loc)
   hotspots[loc] := loc
   y := vertical(loc)
   x := horizontal(loc)
   spot(Color("orange"), y, x)
end

#
# clearspot() removes a "breakpoint" at (x,y)
#
procedure clearspot(spot)
   local s2, x2, y2
   hotspots[spot] := &null
   y := vertical(spot)
   x := horizontal(spot)
   every s2 := \!hotspots do {
      x2 := horizontal(s2)
      y2 := vertical(s2)
   }
   spot(Visualization, y, x)
end

#
# do1event() processes a single user input event.
#
procedure do1event(e, new)
   local m, xbound, ybound, row, column, x, y, s
   case e of {
      "q" |
      "\e": stop("Program execution terminated by user request")
      "s": { # execute a single step
	 step := 1
	 return
	 }
      "C": { # clear a single break point
	 clearspot(location(new.column, new.row))
	 return
	 }
      " ": { # space character: clear all break points
	 if \depthbound then {
	    every y := 1 to numcols do {
	       if not who_is_at(depthbound, y, new) then
		  spot(Visualization, depthbound, y)
	       }
	    }
	 if \breadthbound then {
	    every x := 1 to numrows do {
	       if not who_is_at(x, breadthbound, new) then
		  spot(Visualization, x, breadthbound)
	       }
	    }
	 every s := \!hotspots do {
	    x := horizontal(s)
	    y := vertical(s)
	    spot(Visualization, y, x)
	    }
	 hotspots := table()
	 depthbound := breadthbound := &null
	 return
	 }
      &mpress | &mdrag: { # middle button: set bound box break lines
	 if m := mouse(&y, &x) then {
	    row := vertical(m)
	    column := horizontal(m)
	    if \depthbound then {       # erase previous bounding box, if any
	       every spot(Visualization, depthbound, 1 to breadthbound)
	       every spot(Visualization, 1 to depthbound, breadthbound)
	       }
	    depthbound := row
	    breadthbound := column
	    #
	    # draw new bounding box
	    #
	    every x := 1 to breadthbound do {
	       if not who_is_at(depthbound, x, new) then
		  spot(Color("orange"), depthbound, x)
	       }
	    every y := 1 to depthbound - 1 do {
	       if not who_is_at(y, breadthbound, new) then
		  spot(Color("orange"), y, breadthbound)
	       }
	    }
	 }
      &lpress | &ldrag: { # left button: toggle single cell breakpoint
	 if m := mouse(&y, &x) then {
	    xbound := horizontal(m)
	    ybound := vertical(m)
	    if hotspots[m] === m then
	       clearspot(m)
	    else
	       setspot(m)
	    }
	 }
      &rpress | &rdrag: { # right button: report node at mouse loc.
	 if m := mouse(&y, &x) then {
	    column := horizontal(m)
	    row := vertical(m)
	    if p := who_is_at(row, column, new) then
	       WAttrib("windowlabel=Algae " || image(p.node))
	    }
	 }
      }
end

#
# who_is_at() - find the activation tree node at a given (row, column) location
#
procedure who_is_at(row, col, node)
   while node.row > 1 & \node.parent do
      node := node.parent
   return sub_who(row, col, node)		# search children
end

#
# sub_who() - recursive search for the tree node at (row, column)
#
procedure sub_who(row, column, p)
   local k
   if p.column === column & p.row === row then return p
   else {
      every k := !p.children do
	 if q := sub_who(row, column, k) then return q
      }
end

#
# computeCol() - determine the correct column for a new child of a node.
#
procedure computeCol(parent)
   local col, x, node
   node := parent
   while \node.row > 1 do	# find root
      node := \node.parent
   if node === parent then return parent.column
   if col := subcompute(node, parent.row + 1) then {
      return max(col, parent.column)
      }
   else return parent.column
end

#
# subcompute() - recursive search for the leftmost tree node at depth row
#
procedure subcompute(node, row)
   # check this level for correct depth
   if \node.row = row then return node.column + 1
   # search children from right to left
   return subcompute(node.children[*node.children to 1 by -1], row)
end

#
# Color(s) - return a binding of &window with foreground color s;
#  allocate at most one binding per color.
#
procedure Color(s)
  static t, magenta
  initial {
     magenta := Clone(&window, "fg=magenta") | stop("no magenta")
     t := table()
     /t[E_Fcall] := Clone(&window, "fg=red") | stop("no red")
     /t[E_Ocall] := Clone(&window, "fg=chocolate") | stop("no chocolate")
     /t[E_Snew] :=  Clone(&window, "fg=purple") | stop("no purple")
     }
  if *s > 1 then
     / t[s] := Clone(&window, "fg=" || s) | stop("no ",image(s))
  else
     / t[s] := magenta
  return t[s]
end

lecture 9

3D Graphics Facilities

• Unicon 3D TR
• 3D Examples

• blending texture and foreground/material property
• "buffered 3D mode"
• WSection
• JPEG textures, preliminary PNG support (on Linux)
• dynamic textures
• preliminary transparency support
• meshmode attribute for FillPolygon
• slices and rings attributes for changing the cost and precision of spheres and cylinders
• subwindows
• freetype fonts (needs further test-and-port work)
• tr := Texture(); ...; Texture(tr) to re-use a texture

lecture 10

"Open Mike" Night: HW#3 Demos

Graphic Design(s) of the Day: Tukeys' Multiwindow- and Box-Plots

GUI Monitors

Unicon has a GUI class library, written by Robert Parlett, that has extraordinary capabilities. Although I would like to say that GUI's are amazingly simpler in Unicon than in other languages, it is more honest to say that GUI programming in Unicon has a learning curve comparable to GUI programming in other languages.

Step #1 in GUI exploration is usually to get familiar with the interface builder program; in our case that is IVIB. (Demo of IVIB goes here). IVIB generates code that looks like this. Note that the 70-line application creates a dialog and calls show_modal(), and for a normal VB-style app you then fill in the method bodies for whatever events you've requested. For normal applications, it is not necessary to understand much of the scaffolding in this file and the large classes you inherit behavior from. Note that there is a Unicon Technical Report, UTR#6, which tries to teach the IVIB basics.

IVIB let's you draw a GUI and generates the code for you. For a program execution monitor the main question will be: how to merge the event streams, or how to merge the event processing loops, from the GUI and from the monitored program's events. To accomplish this, you need to know more about the underlying GUI classes.

There are in fact a total of 3 classes that most Unicon GUI programmers need to become semi-comfortable with: Component, Dialog, and Dispatcher. Component is superclass of all basic visible GUI elements in an application: buttons, sliders, lists, editable text boxes, and so on. Components are generally organized hierarchically -- they form a tree in Venn diagram style, with larger background components containing smaller more active components. A Dialog is a component that constitutes the root of some window -- it owns a window and therefor can receive input events, which it then needs to route down the tree to the correct leaf. The Dispatcher class handles the actual event-processing loop, allowing for multiple dialogs, and wall-clock time events in addition to GUI events.

In order to merge the Monitor and GUI event streams, we might do one of the following:

• keep the monitor event loop primary, and poll for GUI events (!)
• keep the GUI event loop primary, and peridically read monitor events (!)

Additional notes on GUI-monitors:

• "piano.icn" had been doing its own input event processing, with E_MXevent at the top level monitor loop and nested loops calling Event() whenever a "breakpoint" was in place.
• can't call Event() cavalierly on your own in the middle of your app -- or GUI won't respond any more. GUI owns input processing, and calls you when a component gets an event.
• how does one "pause" or "single step" in a GUI environment? The GUI is not allowed to freeze. You cannot call EvGet(E_MXevent) to freeze the program, you had better not call EvGet() at all.

lecture 11

Graphic Design of the Day

Unicon 3D: Unfinished Business

Mesh modes?

points

lines

linestrip

lineloop

triangles

trianglefan

trianglestrip

quads

quadstrip

polygon

Transparency?

transparent

subtransparent

translucent

subtranslucent

opaque

Monitoring Memory Allocation and Collection (book ch. 9)

(Per the book, examine a series of memory allocation monitors.)

Mempie

lecture 12

Graphic Design of the Day

Mempie finds a bug

Griswold's claim examined

procedure main()
   t1 := &time
   every i := 1 to 10000000 do p()
   write("10000000 calls: ", &time - t1)
   ce := create |1
   t2 := &time
   every i := 1 to 10000000 do @ce
   write("10000000 @: ", &time - t2)
end

procedure p()
   return 1
end

10000000 calls: 6210
10000000 @: 7920

More memory monitors: mini-memmon and nova

lecture 13

Apologies

A more honest mmm

Monitoring String Scanning (Ch 10)

Some programs use scanning a lot -- they are mostly string scanning -- and others do not use it at all.

The ScanMask events include E_Snew, E_Sfail, E_Spos, E_Ssusp, E_Sresum, E_Srem. E_Spos events are the most frequent. Compared with procedures, what is missing?

For what its worth, evaltree() can model scanning environments just like it does procedure call activity. It can also model built-in functions and operators; all expressions can be modelled as call/ret/susp/resum/fail/rem

Now for a deep-thought question: what kinds of graphic depiction emphasizing what kinds of behavior would make for a genuinely useful string scanning visualization?

Monitoring Structures and Variable References (Ch 11)

What we learn from the simple list visualizer:

• There are basic events for list construction, shape changes, and accesses.
• lists are highly variable in size, frequency of access, and frequency of structural change
• many lists are complex structures almost entirely unnoticed by a tool that visualizes all lists as arrays.
• many or most lists are really just internal glue (non-root)
• many lists are uninteresting, there should probably be a threshold beneath which no screen space is allocated (what should an empty list look like?)

• It is quite possible to infer structures from provided events
• Many programs will have 1-2 huge structures and dozens or hundreds of small ones.

lecture 14

mKE/mKR: the Largest Publically Available Unicon Program

Monitoring Variable References

What do we want to know about variables?

• What proportion of data is static/global, stack, or heap? How can these be measured?
• What data type they hold; whether they ever change type
• Scope: From where-all are they read? From where-all are they assigned?
• Lifetime: are they short, medium, or long-lived?
• Frequency: are they heavily referenced?
• Dependence: are they aliases for data held under other, primary names? Are they pointers into the middle of a larger structure, e.g. for traversal?

gnames

• gnames should continue to support interaction after a program terminates, so you can view variable state posthumously.
• gnames should (maybe) issue a breakpoint if a non-null variable changes type.
• gnames should (maybe) highlight variable assignment and dereferencing, for example flashing black (or white) for a brief time

lecture 15

vars

Under the Covers of the evinit library

We might want to develop a similar architecture for windows! Monitors that use 2D or 3D graphics might want to check and see if their &window is already set, and if so, just draw to it instead of opening a new window. This would allow a GUI for a debugger or multi-visualization tool to allow independently-compiled visualizations to "plug in". Of course, for it to work well, such a model would need to cover how to handle window resizing, and how to handle input by various tools. Subwindows, and subwindow resizing, are more or less adequate to this task.

Monitor Coordinators (Chapter 12)

Eve

Eve configuration

For example:

"Line Number Monitor" /home/jeffery/tools/piano
"UFO" /home/jeffery/tools/ufo
"Algae" /home/jeffery/tools/algae
"Big Algae" /home/jeffery/tools/algae -func -op -step -S 48
"Memory bar chart" /home/jeffery/tools/barmem
"Global variables" /home/jeffery/tools/gnames
"Local Variables" /home/jeffery/tools/vars
"Lists" /home/jeffery/tools/tinylist
"Minimemmon" /home/jeffery/tools/mmm
"Miniloc" /home/jeffery/tools/miniloc
"Scat" /home/jeffery/tools/scat
"String scanner" /home/jeffery/tools/ss

Eve's Global State

unioncset

cset mask that is union of all monitor masks

EventCodeTable

table of lists; keys are event codes, values are "list of interested monitors"

Monitor State

record client_rec(name, args, eveRow, prog, state, mask, enabled)
#
# client() - create and initialize a client_rec.
#
procedure client(args[])
   local self
   self := client_rec ! args
   if /self.name then stop("empty client?")
   self.prog := load(self.name, self.args) | stop("can't load ", image(self.name))
   variable("&eventsource", self.prog) := ¤t | stop("no EventSource?")
   variable("Monitored", self.prog) := &eventsource | stop("no Monitored?")
   /self.state := "Running"
   /self.mask := ''
   /self.enabled := E_Enable
   return self
end

Initialization

   every i := 1 to *clients do
      clients[i].mask := @ clients[i].prog

Event Forwarding

Eve's Main Loop

procedure mainLoop()
   while EvGet(unioncset) do {
      #
      # Call Eve's own handler for this event, if there is one.
      #
      (\ EveHandlers[&eventcode]) ()
      #
      # Forward the event to those EM's that want it.
      #
      every monitor := !EventCodeTable[&eventcode] do
	 if C := event( , , monitor.prog) then {
	    if C ~=== monitor.mask then {
	       while type(C) ~== "cset" do {
		  if C === "abort" then fail
		  #
		  # The EM has raised a signal; pass it on, then
		  # return to the client to get his next event request.
		  #
		  broadcast(C, monitor)
		  if not (C := event( , , monitor.prog)) then {
		     unschedule(monitor)
		     break next
		     }
		  }
	       if monitor.mask ~===:= C then
		  computeUnionMask()
	       }
	    }
	 else {
	    unschedule(monitor)
	    }
      delay(6 < delayval)
      }
end

lecture 16

Papers for the Rest of the Semester

• Apr 3 - Nathan, The Paradox of Software Visualization
• Apr 8 - J Al Gharaibeh, X3D for Software Visualization
• Apr 10 - Wilder, Visualizing Dynamic Memory Allocations
• Apr 15 - Wilder, Software Systems as Cities; Eklund, 3D Representations
• Apr 17 - Z Sharif, Omniscient Debugging, P Nathan, Alg. Anim. using Shape Analysis
• Apr 22 - H Bani Salameh, Memory Graphs; Eklund, Infoviz Using Game Engines
• Apr 24 - J Al Gharaibeh, Visualizing Live Software Systems in 3D, H Bani Salameh, KScope
• Apr 29 -
• May 1 - Z Sharif, Evolve

How many papers do we have time to discuss? Let's have each person present 2. There are really Many sources for software visualization research papers, but let's say that the main ones are ACM SOFTVIZ and IEEE VISSOFT. These every-other-year conferences were in lock-step for awhile, but may have moved to the alternating year from each other so that there is a software visualization conference each year (how nice).

From OOPSLA 2007

• Scalable Omniscient Debugging by Pothier, Tanter, Piquer, about the debugger TOD (presented by al Sharif)

• Visualizing Dynamic Memory Allocations, by Moreta, Telea (presented by Wilder)
• Facilitating Exploration of Unfamiliar Source Code by Providing 2.5D Visualizations of Dynamic Call Graphs, by Bohnet and Dollner (presented by Jeffery)
• Visualizing Software Systems as Cities, by Wettel and Lanza (presented by Wilder)

• X3D Software Visualization, by Ainslow, Marshall, Noble, and Biddle (presented by Al Gharaibeh)
• Metaphor-Based Animation of OO Programs, by Sajaniemi, Byckling, and Gerdt (presented by Jeffery)
• Visualizing Live Software Systems in 3D, by Greevey, Lanza, Wysseier (presented by Al Gharaibeh)
• Mondrian: An Agile Information Visualization Framework, by Meyer, Girba, and Lungu

• Algorithm Animation using Shape Analysis: Visualizing Abstract Executions, by Johannes, Seidel, Wilhelm (presented by Nathan)
• Methodology and Architecture of JIVE, by Gestwicki and Jayaraman

• The Paradox of Software Visualization, by Reiss (presented by Paul)

• 3D Representations for Software Visualization, by Marcus, Feng, and Maletic (presented by Eklund)
• EVolve: An Open Extensible Software Visualization Framework, by Wang, Wang, Brown, Driesen, Dufour, Hendren, and Verbrugge (to be presented by Ziad)
• A System for Graph-Based Visualization of the Evolution of Software, by Collberg, Kobourov, Nagra, Pitts, and Wampler (presented by Jeffery)

• Techniques for Reducing the Complexity of Object-Oriented Execution Traces, by Hamou-Lhadj and Lethbridge
• ADG: Annotated Dependency Graphs for Software Understanding
• Source Viewer 3D (sv3D): A System for Visualizing Multi Dimensionial Software Analysis Data
• MetaViz Issues in Software Visualizing Beyond 3D, by Rilling, Wang, and Mudur
• KScope: A Modularized Tool for 3D Visualization of Object-Oriented Programs, by Davis, Pestka, and Kaplan (Bani Salameh)

• Visualizing the Execution of Java Programs, by Wim De Pauw, et al
• Visualizing Memory Graphs, by Zimmermann and Zeller (Bani Salameh)

• A Menagerie of Program Visualization Techniques, by Jeffery
• Algorithm Animation Using Interactive 3D Graphics, by Brown and Najork
• ZStep95: A Reversible, Animated Source Code Stepper
• Visualization of Dynamics in Real World Software Systems, by Kimelman et al

• Strata-various: multi-layer visualization of dynamics in software system behavior, by Kimelman et al

• Information Visualization Utilising 3D Computer Game Engines

Semester Project Topic Ideas

• is actually useful, to someone
• is usable on any (Unicon) program; is useful on programs having some common property X
• does some actual analysis of the events to extract higher level semantic information
• is scalable; can be run on at least medium sized programs, and preferably large ones
• depicts information in a way that is easily and rapidly interpreted correctly by ordinary humans; contains legends or axes or metaphors or a help system that enables users to understand what they are looking at

• Previous homeowork assignments suggested many possible projects that looked interesting but were too hard to attempt as a HW
• Your own intuitions about what ought to be possible to visualize
• Your readings of the research papers

lecture 17

Final Project Demos

Graphic Design of the Day

Thoughts on visualizing large-ish trees in 2D and 3D.

Tool of the day: redconv

Reading assignment for today's lecture

• The rube Framework for Personalized 3D Software Visualization, by Hopkins and Fishwick
• See also the rube webpage

Generally, after you pick your paper and dates, we need to pass out the reading assignments ahead of time, with either hyperlinks or printed copy of what is to be read. So for example, we have two papers so far assigned that Ziad will be presenting. Also: for each paper/presentation there are some specific questions I'd like you to think about:

• What data domain(s) is the described system able to observe?
• What analysis does the described system perform?
• What visualization or novel data presentation techniques are employed, if any?

Rube

• idea: users should develop their own (visual) metaphors.
• 3d, web-based
• Separate geometry from inter-object semantic relations
• Model Fusion Engine merges object geometry and dynamic behavior models into a 3D scene (VRML scene file).
• generates X3D

Rube methodology

1. choose system to be modeled
2. select structural and dynamic behavioral model types
3. choose a metaphor
4. define mappings/analogies
5. create model

For each different dynamic model type, there may be any number of defined visual metaphors, or a programmer may wish to create a new one. A "water tank" metaphor for a finite state machine would "fill the tank" of whichever state the machine is in, and the water would be pumped over to a different tank whenever a transition to a new state occurs.

In a gazebo metaphor, a person would indicate the state, and a transition would be depicted by that person walking.

Rube Summary

• There are benefits to a visualization system that supports 3D models and external tools. The benefits include richer, reusable visual metaphors, and better portability.

lecture 18

Quote of the Day

Graphic Design of the Day: Kiviat Diagrams

Kiviat diagrams are easy to criticize. There are problems with the relative scales of dimension; do you reduce them all to 0.0-1.0 ranges, or not? There are problems to identify normal or acceptable ranges of values. There are problems that adjacent dimensions don't really have any more connection with each other than remote dimensions, but the Kiviat makes them look like they do. The area inside the Kiviat shape is really meaningless.

HW#5 statii

What About the Dynamic Analysis?

• The Concept of Dynamic Analysis by Tom Ball.

1. precision of information; derived from 1+ actual program run(s)
2. input-centric mentality; shows dependence of internal behavior on particular inputs of a given execution

frequency spectrum analysis

analyze frequencies of different kinds of events, e.g. to identify related computations

coverage concept analysis

FSA

• low-frequency operations are generally at higher-levels of abstraction
• frequency clusters -- if foo and bar are both called 1033 times, there is probably a connection
• frequencies that match a program's input or output domain may reveal portions of the program related to input or output.
• frequencies can tip you off regarding the big-Oh complexity of an algorithm

CCA

coverage profile

profile of what was executed (no frequency info)

concept analysis

(T, E), T a set of tests and E a set of program entities, is a concept if every test in T covers all of E and no test not in T covers all of E.

More Dynamic Analyses

statistical

Summarizing data by accumulation or averaging to give the big picture. _ FSA seems to be an example of statistical analysis.

pattern-of-interest

parsing event patterns to find bugs, or even just to find items of interest. note that event pattern parsing must carefully define its domain, skipping over events that don't effect the pattern match. note also that event pattern parsing will usually be done non-deterministically and maybe in a massively-parallel model

higher-level-events

one variant of the pattern-of-interest notion is to identify events at a higher semantic level, such as aggregates of lower level events, or application domain events

categorization

figuring out when a class implements a stack, or is using dynamic programming, or whether it employs a feature for which a specialized tool is available

profiling; coverage

treating hotspots and coldspots specially; for example the former deserve extra performance tuning monitors, while the latter deserve extra typographic paranoia monitors

lecture 19

Reading assignment

Graphic Design of the Day: Perspective Wall

Research Paper of the Day: Bohnet and Dollner

• millions of lines of unfamiliar code
• to add a feature, one must
  • identify the relevant "entry points"
  • read the source code
• current IDE's poorly suited to this task
  • to follow the calls, one is switching constantly between files
  • the source navigation tree does not show connections, does not emphasize the files relevant to the feature under study, and does not scale well to hundreds/thousands of files.
  • no context for navigation, have to go-and-see, can't see-and-go
• idea: use dynamic call graph data to organize navigation activity
  • similar a dynamic tracing facility...but the IDE uses the data to emphasize or structure the navigation bar to the relevent code automatically.
• superimpose the call graph structure on the source code views
• present a perspective-wall-like view of the call graph...
• apply level-of-detail techniques; present more information for the nearer / focus nodes where there is space for it.

lecture 20

Nate's Structure Monitor

Paul Nathan presents comments on Steve Reiss' Paradox of SV paper

Metaphor-Based Animation of OO Programs

• SV conference pub is a poster abstract; Finnish author has written some other related papers.
• Context is novice programmer education, a perpetually popular SV area.
• Project was done as Flash animations.
• watch panel metaphor for instances
• role metaphors for member variables
• blueprint for class, found in a blueprint book; blueprint page will visually depict methods, which don't show on the watch panel
• workshop for method invocation, workbench for its result (lame)
• method call is also visualized as a envelope ("message passing") that delivers parameters to the watch panel
• object references use a "pennant" metaphor; color is used to match. No pennants = garbage to be collected
• variable roles include: fixed value, organizer, stepper, most-recent holder, one-way flag, most-wanted holder, gatherer, container, walker, follower, temporary, other

lecture 21

X3D for Software Visualization

Mondrian

Challenges for InfoVis Engines

theStackFrame.getValue(theLocalVariable)
... transmitted via a socket / JDWP ...
jvmti->GetLocalInt(frame, slot, &intValue)
... result transmitted back...