DotGNU ideas list: Summer of Code

The DotGNU project is a Free Software implementation of the .NET and Mono platforms and spans many different programming areas: from low-level tasks like code generators to compilers, to class libraries and GUI applications.

The Portable .NET implements Just-In-Time compilation functionality. Unlike other JIT's, libJIT (a reusable JIT library) is designed to be independent of any particular virtual machine bytecode format or language. If you run Portable .NET on a machine for which a native code generator is not yet available, then Portable .NET will fall back to interpreting the code.

Read the libjit rationale for instruction and rationale for the DotGNU JIT Library (libJIT).

If you want to modify or extend these tasks or have your own ideas, please see the GNU Project guidelines for Summer of Code projects. If you want to discuss potential projects with the DotGNU team, we'd love to talk to you about it. You can contact us by email on the DotGNU mailing list, or by IRC on the or #dotgnu channels on

  1. Add ahead-of-time compilation support in libJIT (Complexity: medium-high)

    The libJIT library contains routines that permit pre-compiling JIT'ed functions to an on-disk representation. This representation can be loaded at some future time, to avoid the overhead of compiling the functions at runtime. We use the ELF format for this purpose, which is a common binary format used by modern operating systems and compilers.

  2. Port libJIT to a new architecture or improve existing architecture support (Complexity: medium-high)

    You could port libJIT to a new architecture, for example OpenRISC, SPARC, MIPSEL and so on or improve an existing code generator (x86, arm...). The libJIT manual describes the steps needed to for porting libJIT to new architectures.

  3. Enhance the libJIT interpreter (Complexity: medium)

    LibJIT includes an interpreter for running code on platforms that don't have a native code generator yet. This reduces the need for programmers to write their own interpreters for such platforms. Essentially, this project means making the regression tests with 'make check' in the Portable .NET directory work with the interpreter.

  4. Enhance libJIT optimization (Complexity: medium-high)

    For example, implement inlining, enhance constant propagation or dead-code elimination.

  5. Work on memory leaks, implement a special feature in the Garbage Collector. (Complexity: high)

    It would be beneficial to have a method in GC which can enumerate all objects which reference a specified object. The signature of this method might be, for example, object[] GC.GetReferences( object o ).

  6. Fill the gaps in Portable.NET's System.Windows.Forms (Complexity: medium)

    The Portable .NET Windows.Froms library implements much of .NET 1.1, but some classes are still missing.

  7. Replacing CIL with native code. (Complexity: high)

    DotGNU contains a code generator that can be used for Just-in-Time compilation at runtime. Code can also be compiled ahead of time to produce native code before it's needed. The goal is to modify the runtime and compilation so that the bytecodes can be safely removed from a program and a single image is shipped containing both metadata and native code.

  8. Implement generics or any other C# 2.0, 3.0 feature. (Complexity: very high)

    The Portable .NET C# compiler is based on the treecc tool.

  9. C# bindings for Allegro (Complexity: medium-high)

    This includes not only being able to call Allegro functions from C#, but also being able to do so in a way which 'feels natural' for the C# language.

Back to