Semantics of Byte-Streams

The main issue of visualizing a program is the way, how to display a byte-stream. Code and data in memory are nothing else than a large amount of bytes. Code is not worth displaying, because there is not to really any activity in the code section in memory, except the user does code-patching. When we are speaking of bytes, we just mean raw data.

  

Figure 3: Block Diagram of Visualization Process

A core dump out of an active program provides one stream of bytes. Our idea is, seeing the byte-stream as a two-dimensional array (mapping a one-dimensional stream with the square-root function).

The bytes are transmitted from the steering program by UNIX sockets. As a result, several streams can be transmitted parallel.
Basically, there are two different delivery types:

• post-mortem
• on-the-fly (real-time)

In the post-mortem approach, the whole information is being collected over a period of time. Independently from execution-time, the user can view the activity of the program at any time.
In contrast to post-mortem approach, the on-the-fly approach the data-stream is provided during program execution every $\delta$ seconds, or even in real-time.

Figure 3 describes the visualization process in a schematic way. The PreScan Master forks PreScan Clients on each node of the parallel computer. After attaching to the processes, every PreScan Client transmits the raw data-stream over UNIX sockets. MostVis Clients - running as threads - receive the information and store them into a global data array.
The MostVis Manager collects these information and specifies the delivery type (post-mortem, on-the-fly). In dependence on this type, the Display Manager fetches the data and displays it in the CAVE (Cave Automatic Virtual Environment).