diff options
Diffstat (limited to 'web/mono-todo')
| -rw-r--r-- | web/mono-todo | 266 |
1 files changed, 266 insertions, 0 deletions
diff --git a/web/mono-todo b/web/mono-todo new file mode 100644 index 00000000000..c57c430c9b2 --- /dev/null +++ b/web/mono-todo @@ -0,0 +1,266 @@ +* 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: + <ul> + <li> Write documentation. + <li> Write regression tests. + <li> Complete the implementations of the class libraries. + <li> Help fix the bugs filed in our bugzilla database. + </ul> + + 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: + + <ul> + * <b>JIT compiler</b>: tasks can be: adding more optimizations, reducing + compile time, porting to different architectures. + + * <b>AOT compiler</b>: optimizing the compiler output and the AOT loader, + better support for multiple application domains. + + * <b>VM runtime</b>: optimizing the runtime data structures, experimenting with + different garbage collectors, integration with different component models. + + * <b>Class library</b>: many opportunities in the implementation of regular + expressions, Xml related technologies (XPath, XLST, etc). + + * <b>Compilers</b>: writing compilers, interpreters and runtimes for langauges + so that they run on the CLR (using Reflection.Emit support, for example). + </ul> + +Happy hacking! + +<table border=1 cellspacing="0" cellpadding="0"> + <tr> + <th>Area<th>Description<th>Difficulty<th>Time estimate<th>Bugzilla ID + </tr> + + <tr> + <td>System assembly (mcs/class/System/) + <td>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. + <td>Medium-hard (thesis subject) + <td>2-4 months + <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52605">52605</a> + </tr> + + <tr> + <td>JIT (mono/mini/) + <td>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). + <td>Hard (thesis subject) + <td>2-4 months + <td>not assigned + </tr> + + <tr> + <td>JIT (mono/mini/) + <td>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. + <td>Medium-hard (thesis subject) + <td>3-6 months + <td>not assigned + </tr> + + <tr> + <td>JIT (mono/mini/) + <td>Port the JIT to additional architectures. + Currently ports exist for x86, ppc, sparc and s390. + + Ports to more architectures are welcome as well. + <td>Medium-hard + <td>3-6 months per arch + <td>not assigned + </tr> + + <tr> + <td>Runtime and JIT (mono/metadata and mono/mini/) + <td>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. + <td>Medium-hard (thesis subject) + <td>3-4 months for each + <td>not assigned + </tr> + + <tr> + <td>Runtime and JIT (mono/metadata and mono/mini/) + <td>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. + <td>Medium-hard (thesis subject) + <td>4-5 months + <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52606">52606</a> + </tr> + + <tr> + <td>Runtime and JIT (mono/metadata and mono/mini/) + <td>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). + <td>Hard (thesis subject) + <td>6-8 months + <td>not assigned + </tr> + + <tr> + <td>Compilers for dynamic languages + <td>Write a IL compiler and runtime support for dynamic languages like + Python, Perl, Ruby, PHP. + <td>Medium-hard (thesis subject) + <td>6-12 months + <td>not assigned + </tr> + + <tr> + <td>Linker tool. + + <td>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. + + <br>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. + + <td>Medium + <td>4-6 months + <td> + </tr> + + <tr> + <td>Tools + <td>Write an implementation of the MSBuild compilation tool available in .NET 1.2 + <td>Medium + <td>4-6 months + <td>not assigned + </tr> + <tr> + <td>Build tools. + <td>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. + <td>Easy + <td>1-2 weeks + <td>not assigned + </tr> + <tr> + <td>Documentation. + <td>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. + <td>Easy + <td>Ongoing work. + <td>not assigned + </tr> + <tr> + <td>Documentation + <td>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. + <td>Easy + <td>Ongoing work. + <td>not assigned + </tr> + <tr> + <td>Documentation Tools + <td>The Monodoc collaborative service needs a better + administration tool than it has today; Someone needs + to redo the UI and streamline its process. + <td>Easy + <td>2-3 months. + <td>not assigned + </tr> + <tr> + <td>Comment Service API + <td>Design a full system for comments and ratings so + people can annotate the documentation in Monodoc. + <td>Easy + <td>2-3 months. + <td>not assigned + </tr> + <tr> + <td>System.Data updates + <td>.NET 1.2 will introduce many new updates to the + System.Data namespace: MARS and ObjectSpaces are the + big ones. + <td>Medium + <td>6-9 months. + <td>Work with the mono-devel-list to keep track of things. + </tr> + <tr> + <td>System.XML updates + + <td>.NET 2.0 will introduce many new updates to the + System.Xml namespace: XQuery and new XPathDocument are + the big changes. + + <td>Medium + <td>6-9 months. + <td>Work with the mono-devel-list to keep track of things. + </tr> +</table> + |