Monday, November 9, 2009

PRES: Probabilistic Replay with Execution Sketching on Multiprocessors

This paper is interesting to read (took few passes to get hold of what authors are saying) and like the ideas presented. Looking forward for good discussion in the class tomorrow --

What do you expect from a debugging tool?

Let me examine the internal state of the application throughout the execution of it so that I can see what is going on inside while it is executing the code.

What debugging tools do you usually use? What are good and bad about them?

I use Rational Software products server web sphere server (based of Eclipse) run in debug mode and look at the system out and error logs to debug the app and server allow to be started in debug mode and we can insert the break points so that when server steps in to that place it will stop and take details of the details and we can also do line debugging as we step through the app.
It is good because it will show us the variable values and method interaction etc… at time that were setup through break points. However, they are bad for concurrent programming debugging.

I wish this tool have a way to more naturally step through the interactions rather than stepping through the breakpoints or prescheduled items and produce the results of the values and interactions as it completes the task.

What are the challenges of debugging a sequential program? What are additional challenges of debugging a parallel program?

Debugging in a sequential program is relatively easy with a tool. Just give some known input with an expected output, and step through the application to see how the input is changed it resulted in bad or unwanted output than what was expected. Debugging parallel programs is harder as we need to know how the work is divided and what to expect the results for the piece that is getting executed on a single etc…

How important is replay for debugging?

If we can’t reproduce the bug and know where it is coming from then it is very hard to be able to fix it and know that it (same bug) won’t be occur again in the future. Debugging allow us to efficiently reproduce the bug and lead us or show us the potential reason for the bug so that we can fix it.


If you need to design a deterministic replay system, how are you going to do it for sequential programs? Does it work for parallel programs? If no, how to make it work?

For sequential programs, we can take state information at various points in the program that would give enough information to known where the inconsistencies are occurring and then the deterministic algorithm can use this information to find the reply. The same idea can be applied to parallel programs, but they may need more current state information gathered from different cores and give to deterministic algorithm to find the reply back.

No comments:

Post a Comment