Table of Contents
Mono Tasks
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!
JIT Compiler
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| Delegate Optimization | There a number of new optimizations for special cases of delegates, these are quite visible in IronPython 2.0 and DLR-based applications (there is a significant performance drop for Mono while it should have been a performance increase) | Medium | 1-2 months | See this bug (http://bugzilla.ximian.com/show_bug.cgi?id=81663) for details on what we know. |
| Verifier work | We need to complete the Mono verifier before we can have a full sandbox setup (for use in Moonlight and other sandbox setups) | Medium | 2-3 months | N/A |
| Stack Overflow Prevention | We want to fully support Stack Overflow prevention. See this page (http://bugzilla.ximian.com/show_bug.cgi?id=81685) for details on the problem and the current ideas | Medium | 1 month | N/A |
| Generics Code Cleanup | Need details from Paolo on the work needed | Medium | 1 month | N/A |
| AOT support for 2.0 assemblies | Currently Mono Ahead-of-Time compilation infrastructure is unable to pre-compile 2.0 based assemblies. | Medium-hard | 3-6 months | Being worked on. |
| Performance Reasearch | Mono is known to be not as performance as the .NET Framework, but not enough information is available about where the actual weak spots are. Tests like SciMark and IronPython pybench could be used to understand our current limitations | Medium-hard | 1-3 months | N/A |
| Generics Code Sharing | Currently Mono does not do any sort of code sharing when generics are used, and this could lead to unnecessary bloat, this should be implemented at some point | Medium-hard | 3-4 months | N/A |
| JIT (mono/mini/) | Port the JIT to additional architectures. Currently ports exist for x86, x86-64, ppc, sparc, mips and s390. Ports to more architectures are welcome as well. | Medium-hard | 1-3 months per arch | N/A |
| 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. 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 | Zoltan Varga is working on this. |
Garbage Collector
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| 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). | Hard | 6-8 months | Paolo is currently working on this, code has been checked into SVN and can be enabled by using the "sgen-gc" option. |
| GC: card table | The new generational GC currently uses a remebered set to keep track of pointers in the old generation that point to the new generation. This mechanism can be improved upon by using a card table setup. | Medium | 2-3 months | N/A |
VM Runtime
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| 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 | Currently being worked on. See this Bugzilla number for updates: 52606 (http://bugzilla.ximian.com/show_bug.cgi?id=52606) |
| 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 | Jonathan Chambers is working on COM Interop. Low priority. |
Tools
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| Tools | ||||
| 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. | N/A |
| Coding Style compliance |
Using Cecil to inspect binaries: public APIs should adhere whenever possible to the coding guidelines for .NET components, and it would be nice to have a free tool for Mono users that does for non-Windows systems what FxCop does on Windows. |
Medium | 3-4 Months | Gendarme |
| Disassembler/assembler |
although today we have both tools, we are not very happy with our disassembler as it uses the Mono internal calls which are not really designed to cope with incomplete assemblies (we have an all-or-nothing codebase in this scenario). |
Medium | 3-4 Months | jbevain is working on ildasm, still need to update the assembler. |
| Code optimization using Cecil |
this is a longer-term project, but today compilers that target the CIL are known to generate fairly straightforward CIL code leaving most of the work to the JIT engine. An optimizer that could perform some tasks before the JIT compiler hits the code would be useful. Although our code generator is fairly good, and getting better the most effective optimizations are never turned on for JIT-use as they are very time consuming. There are a couple of temporary measures that can be taken to address this issue (ahead-of-time compilation and dynamic recompilation). Both have small drawbacks. A code optimizer would convert a CIL stream into a different CIL stream that is compatible but has applied some optimizations before the JIT sees them. These optimizations could be a lot more complex than what the JIT compiler can do today doing things like loop unrolling or processing a file to automatically multithread some pieces of the program. It is rumored that the MS C++ compiler produces better code than the C# compiler as it does do some IL-level loop unrolling for example. |
Medium-Hard | 3-4 Months | Must validate claims, could reuse the semantic information from a bug-finding tool. |
| Linker/diet program |
Mono today ships a 'monodiet' program that can reduce the size of binaries: it is basically a garbage-collector for CIL code. But the code is written in C and is not a foundation for growth, we would like to rewrite this tool using Cecil |
Medium | 3-4 Months | Linker |
| Peverify |
Using Cecil to inspect CIL streams: a tool thats checks if your code is type safe. |
Medium | 2-3 weeks | N/A |
| Permview |
Using Cecil to display declarative security attributes stored in assemblies metadata. |
Easy | 1 Week | done (http://svn.myrealbox.com/source/trunk/cecil/permview/) |
Class Libraries
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| 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 | [1] (http://bugzilla.ximian.com/show_bug.cgi?id=52605) |
| System.Data updates | .NET 1.2 will introduce many new updates to the System.Data namespace. | Medium | 6-9 months. | Work with the mono-devel-list to keep track of things. |
| 2.x updates. | Many new features are avaialble in the 2.x framework, see the Resources page for a Web-explorer of differences, help is needed to complete these tasks | Medium | Ongoing work | Work with the mono-deve-list to keep track of things. |
Documentation
| Area | Description | Difficulty | Time estimate | Additional information |
|---|---|---|---|---|
| Version Information | Update monodocer so it can consume the output of corcompare (our tool to track differences in APIs) and flag documentation with the proper XML elements to state when the API first became available | Medium | 1 months | N/A |
| Integrate 2.x documentation | Integrate the documentation from the new ECMA standard into our class libraries. | Easy | 1 week | N/A |
| C# specification | Integrate the new C# specification into Monodoc | Easy | 1 week | N/A |
| 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. | N/A |
| Comment Service API | Design a full system for comments and ratings so people can annotate the documentation in Monodoc. | Easy | 2-3 months. | N/A |
Other
| Area | Description | Difficulty | Time estimate | Additional |
|---|---|---|---|---|
| Compilers for dynamic languages | Write a IL compiler and runtime support for dynamic languages like Python (Done: see IronPython and PHP.NET), Perl, Ruby. | Medium-hard (thesis subject) | 6-12 months | N/A |
| System.Data updates | .NET 2.0 will introduce many new updates to the System.Data namespace. | Medium | 6-9 months. | Work with the mono-devel-list to keep track of things. |
| Tests for Class Libraries | Write NUnit tests for class libraries where missing | Medium | 1-2 hours per class | N/A |
