SRG: NetOS:
Student Projects 2000

Language Support
UoCCL


 bdb: Backwards DeBugger Language  2000  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 (but perhaps more useful) system could be developed at a lower level. Rather than supporting direct reverse execution of every instruction it would periodically checkpoint the user-space process state and roll forwards from one of these checkpoints.

Special Resources: dependent on the approach taken.


 Java thread scheduler in Java Language  2000  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.


 Incremental x86 linker Language  2000  Student Projects  NetOS 

Contact: Austin Donnelly  email

Large applications take a long time to do the final link, since so many object files are being pulled together. As software is developed, often only a small subset of the object files change, yet when re-linking, all are considered as if each was fresh. With incremental linking, only the changed objects are replaced, and references to symbols that have moved are patched up where they occur.

This project would implement such an incremental linker. It may be easiest to write a traditional linker then extend it do incremental links, rather than to modify a libbfd-based existing linker (eg GNU ld). This project is likely to be very difficult.

Special Resources: access to SRG Linux machines.


 Precompiled header support for gcc Language  2000  Student Projects  NetOS 

Contact: Austin Donnelly  email

Typically, much of a compiler's time is spent parsing its input to generate some internal representation. Actual code generation takes up less of the compiler's run time. A technique for speeding up the compilation process is known as ``precompiled headers,'' where the compiler dumps an internal representation of the result of its parse of the header files to some cache files. Later invocations of the compiler can directly load the precompiled headers rather than parsing the existing header text.

Potential problems include that fact that the order of inclusion may affect the header's behaviour, the #defines in action at the time of inclusion may modify the header, and the header may in fact have many different paths through it due to conditional compilation #ifdefs: one header may generate many different precompiled headers depending on the environment it is included into.

This project would modify gcc/cpp to generate and use precompiled headers. This is likely to be a difficult project principally since the gcc source is large and complex.

Special Resources: access to SRG Linux machines.


  Language  2000  Student Projects  NetOS 
Valid HTML 4.0!
 Richard.Mortier@cl.cam.ac.uk
$Id: runtime.html,v 1.4 2000/08/01 15:00:14 rmm1002 Exp $