SRG: NetOS:
Student Projects 1999

Run-Time Level Support
UoCCL


 bdb: Backwards DeBugger Run-Time  1999  Student Projects  NetOS 

Contact: Tim Harris  email

Traditional interactive debuggers are frustrating to use. When a programmer is trying to track down a problem they have to set breakpoints in the code, run the program until it reaches a breakpoint and then single-step through the code until they realize what is going wrong. They often have to single-step through hundreds of lines of code, or they have to re-run the program many times because the breakpoint is reached several times before the bug is seen.

A more natural way of working would be to single-step backwards through the code, tracing back from a point where the program has clearly gone wrong, towards the point at which it initially failed.

Providing this kind of facility is clearly hard: an operation like a = 42 cannot be executed in reverse because the old value of "a" has been lost. One reasonably straightforward way of tackling this problem would be to modify the code being debugged so that it keeps a log of values before they are lost. A simple circular buffer could be used, and the size of the buffer tuned to control how far backwards it will be possible to step. If this problem is tackled in Java then it should be possible to re-use an existing code-rewriting tool to transform the instructions.

A more adventurous approach is to transform the program into one composed of primitive operations which are inherently reversible: for example a direct assignment could not be expressed directly, but a swap operation could. A further possible approach is to checkpoint the program state perodically and to step backwards by returning to the previous checkpoint and re-executing the subsequent instructions.

Anyone considering this project may also be interested to read Reverse Execution of Programs by Bitan Biswas and R Mall in the April 1999 issue of ACM SIGPLAN Notices.

Special Resources: dependent on the approach taken.


 Java thread scheduler in Java Run-Time  1999  Student Projects  NetOS 

Contact: Tim Harris  email

A traditional implementation of the Java Virtual Machine (JVM) is composed of a large amount of native code, probably written in C and assembly language. As well as the core Java interpreter, this code is responsible for dealing with memory allocation, managing files and network connections and (in some cases) for scheduling the threads within the JVM.

Many of these functions could in fact be written directly in Java. There are several reasons why doing so might be desirable: it could provide additional flexibility to applications running over the JVM, it could make it easier to replace components of the JVM without replacing the entire system and the robustness of the implementation of these component could benefit from the strong typing and security checks performed on Java code.

This project proposes re-implementing some component of a JVM in Java. A good candidate is the thread scheduler, since the design of the new scheduler can benefit from existing techniques that have been developed for writing user-level thread schedulers in other environments.

Special Resources: access to the JVM source code and an account on a Linux or SPARC Solaris machine with sufficient space to build it -- approx 30MB required.


 Using type information in garbage collection Run-Time  1999  Student Projects  NetOS 

Contact: Tim Harris  email

This project is an extension of some work I did last year on how the type information that the Java Virtual Machine (JVM) maintains at run-time can be used to help the garbage collector. The basic idea is to analyze the class definitions in a Java program to try to work out where there are pieces of the heap which cannot refer to one another. This can allow the collector to reclaim space occupied by garbage data without having to scan the entire heap.

There are several extensions that could be made to the prototype implementation: for example by using the additional information provided by one of the proposals for adding parametric polymorphism to Java, or by using different garbage collection techniques for different parts of the heap.

Special Resources: access to the JVM source code and an account on a Linux or SPARC Solaris machine with sufficient space to build it -- approx 30MB required.


  Run-Time  1999  Student Projects  NetOS 
 Richard.Mortier@cl.cam.ac.uk
$Id: runtime.html,v 1.6 1999/10/04 14:07:14 tlh20 Exp $