This page is likely outdated (last edited on 23 Nov 2009). Visit the new documentation for updated content.
Todo
Table of contents |
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 for details on what we know. |
Generics Code Cleanup | Need details from Paolo on the work needed | Medium | 1 month | N/A |
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 |
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
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 |
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
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.
Class Libraries
Area | Description | Difficulty | Time estimate | Additional information |
---|---|---|---|---|
System assembly (mcs/class/System/) | Complete 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] |
System.Data.Linq | Finish Mono’s System.Data.Linq.dll implementation. Mono’s System.Data.Linq.dll implementation is based upon the DbLinq project, which also serves as the basis for Mono’s sqlmetal.exe tool. DbLinq supports multiple databases (though such support requires “workarounds” to maintain API compatibility with .NET). Checkout DbLinq Bugzilla and all “known test failures” (tests marked with an Explicit attribute). The DB vendor plugin API also needs re-working. | Medium | 6-9 months | DbLinq Project, DbLinq Mailing List |
System.Data.Services | .NET 4.0 introduces a new data model for exchanging data . | Medium | 6-9 months. | Work with the mono-devel-list to keep track of things. |
Windows Workflow 4 | .NET 4.0 introduces a simpler and smaller workflow platform. | Medium | 6-9 months. | Work with the mono-devel-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 |
C# specification | Integrate the new C# specification into Monodoc | Easy | 1 week | 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 |
Web-editing for Monodoc | Modify Monodoc so that it can be used over the web to accept contributions and edit the existing documentation | Easy | 1 months. | N/A |
Other
Area
Description
Difficulty
Time estimate
Additional
Discussion
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).