mono-logo Downloads | Daily snapshots | Screenshots | Documentation | Bugs | Blogs

Mono hacking TODO list

From time to time people that want to contribute to Mono ask on the mailing list what they can help with. The generic answer is always:

  • Write documentation.
  • Write regression tests.
  • Complete the implementations of the class libraries.
  • Help fix the bugs filed in our bugzilla database.

The proposed tasks are very important for the Mono project and are suitable for people that can dedicate even just an hour per week to contribute. But some people may need something more focused to work on, such as students that want to do a thesis on their contribution to Mono. For such people (and also for professors who want ideas for thesis regarding JIT or VM technologies), here is a list of tasks that need attention.

The estimated time to complete any of the tasks is between 1 week to several months to accomodate for different hacking possibilities.

Note on the time estimates: they are very rough estimates, a smart and dedicated hacker can complete the tasks in half of the minimum time, a part-time hacker that also has a social life can take more than double the max time, but there's nothing to worry as long as progress is being done.

If some people (or group of people) want to take on a task, they should write to the mono-devel mailing list and in the relative bugzilla bug report. Discussions about how to implement a feature or additional information on the task should be mailed to the list or in the bugzilla report as well so that people can keep informed on the progress or have the information needed to start contributing. Mono is an excellent platform for research on JITs, virtual machines and specifically the CLR because it provides an advanced free software implementation that can be used as a basis for more optimizations, new approaches to problems and new features.

There are different areas of interest where high-level contributions can be made:

    * JIT compiler: tasks can be: adding more optimizations, reducing compile time, porting to different architectures.

    * AOT compiler: optimizing the compiler output and the AOT loader, better support for multiple application domains. * VM runtime: optimizing the runtime data structures, experimenting with different garbage collectors, integration with different component models. * Class library: many opportunities in the implementation of regular expressions, Xml related technologies (XPath, XLST, etc).

    * Compilers: writing compilers, interpreters and runtimes for langauges so that they run on the CLR (using Reflection.Emit support, for example).

Happy hacking!

AreaDescriptionDifficultyTime estimateBugzilla ID
System assembly (mcs/class/System/) Implement the IL-based regular expression engine. Instead of intepreting the regular expression pattern, a method is created at runtime using Reflection.Emit. This makes for faster pattern matching because there is no intepreter overhead and the matching code is jitted to fast native code. Bonus points if the compiled regular expression is compatible with the ones generated by the MS runtime. Medium-hard (thesis subject) 2-4 months 52605
JIT (mono/mini/) Implement common subexpression elimination. Global and local common subexpression elimination needs to be implemented to achieve better performance. The local case is easier and may take just one month. It should be implemented in the context of the SSA framework (mini/ssa.c). Hard (thesis subject) 2-4 months not assigned
JIT (mono/mini/) Optimize AOT compiler output. Currently the code generated by the AOT compiler may be significantly slower than jitted code. This is mostly because the AOT code supports multiple application domains and some values that are constant at JIT-time are not constant at AOT-time. It may be needed to write a simple dynamic linker and/or binary object writer. Bonus poinst if it supports ELF, PE/COFF and mach-O binary formats. A possible idea for improvements is also the use of appdomain ID-indexed tables to get at the appdomain specific data. Medium-hard (thesis subject) 3-6 months not assigned
JIT (mono/mini/) Port the JIT to additional architectures. Currently ports exist for x86, ppc, sparc and s390.

Ports to more architectures are welcome as well.

Medium-hard 3-6 months per arch not assigned
Runtime and JIT (mono/metadata and mono/mini/) Add support for COM and/or XPCOM and/or ORBit. We need a way to seamlessy use existing component technologies inside the mono runtime. The COM support needs to match the MS runtime behaviour and is targeted at windows systems. XPCOM and ORBit support are important on Unix platforms. Bonus points for developing the runtime support so that different component systems can be used at the same time. Medium-hard (thesis subject) 3-4 months for each not assigned
Runtime and JIT (mono/metadata and mono/mini/) Implement support for Code Access Security. Support needs to be added to the JIT and the runtime to ensure code that executes privileged operations is permitted to do so. The task includes loading the security information from metadata, collecting evidence, inserting calls to the permission objects, stack walking to collect security info. Medium-hard (thesis subject) 4-5 months 52606
Runtime and JIT (mono/metadata and mono/mini/) Implement support for a generational GC. We're currently using a conservative non-moving GC. Support for a generational and moving GC requires changes to the JIT (to record locations in frames as well as registers that may contain pointers to GC-allocated memory) and to the runtime code (when objects are manipulated directly we should make sure they are pinned and reachable by the GC also in the C unmanaged code). Code from an existing precise GC such as the ORP one could be reused or a new GC may be developed (increasing the estimated development time). Hard (thesis subject) 6-8 months not assigned
Compilers for dynamic languages Write a IL compiler and runtime support for dynamic languages like Python, Perl, Ruby, PHP. Medium-hard (thesis subject) 6-12 months not assigned
Linker tool.

Write a tool that given a list of methods and classes extracts them from an existing assembly and produces a new assembly with these classes and any dependencies they might have.
The idea is to have a way of creating custom libraries that can either be embedded with Mono's bundle setup or to create smaller editions of the libraries for embedded systems.

Medium 4-6 months
Tools Write an implementation of the MSBuild compilation tool available in .NET 1.2 Medium 4-6 months not assigned
Build tools. Currently it is easy for people doing daily updates from CVS to break their installation. Design a mechanism by which Mono never fails to compile. Easy 1-2 weeks not assigned
Documentation. Editorial review of the Monkeyguide: The monkeyguide is known to contain outdated statements, it needs to be reviewed and it needs an editor to take control over it. Some simple tasks include flattening out the Monkeyguide, since it is too nested today. Easy Ongoing work. not assigned
Documentation GNOME.NET Chapter should probably be separated from the Monkeyguide. This is probably the most complete chapter, but it is burried in various nested levels of stuff, and because of this, it is not being updated. Write a chapter on custom control authoring and common patterns of app development. Easy Ongoing work. not assigned
Documentation Tools The Monodoc collaborative service needs a better administration tool than it has today; Someone needs to redo the UI and streamline its process. Easy 2-3 months. not assigned
Comment Service API Design a full system for comments and ratings so people can annotate the documentation in Monodoc. Easy 2-3 months. not assigned
System.Data updates .NET 1.2 will introduce many new updates to the System.Data namespace: MARS and ObjectSpaces are the big ones. Medium 6-9 months. Work with the mono-devel-list to keep track of things.
System.XML updates .NET 2.0 will introduce many new updates to the System.Xml namespace: XQuery and new XPathDocument are the big changes.

Medium 6-9 months. Work with the mono-devel-list to keep track of things.

webmaster@go-mono.com