use webformat
[mono.git] / web / mono-todo
1 * Mono hacking TODO list
2
3         From time to time people that want to contribute to Mono ask
4         on the mailing list what they can help with. The generic
5         answer is always:
6         <ul>
7         * Write documentation.
8         * Write regression tests.
9         * Complete the implementations of the class libraries.
10         * Help fix the bugs filed in our bugzilla database.
11         </ul>
12
13         The proposed tasks are very important for the Mono project and
14         are suitable for people that can dedicate even just an hour
15         per week to contribute.  But some people may need something
16         more focused to work on, such as students that want to do a
17         thesis on their contribution to Mono. For such people (and
18         also for professors who want ideas for thesis regarding JIT or
19         VM technologies), here is a list of tasks that need attention.
20
21         The estimated time to complete any of the tasks is between 1
22         week to several months to accomodate for different hacking
23         possibilities.
24
25         Note on the time estimates: they are very rough estimates, a
26         smart and dedicated hacker can complete the tasks in half of
27         the minimum time, a part-time hacker that also has a social
28         life can take more than double the max time, but there's
29         nothing to worry as long as progress is being done.
30
31         If some people (or group of people) want to take on a task,
32         they should write to the mono-devel mailing list and in the
33         relative bugzilla bug report. Discussions about how to
34         implement a feature or additional information on the task
35         should be mailed to the list or in the bugzilla report as well
36         so that people can keep informed on the progress or have the
37         information needed to start contributing.
38         
39         Mono is an excellent platform for research on JITs, virtual
40         machines and specifically the CLR because it provides an
41         advanced free software implementation that can be used as a
42         basis for more optimizations, new approaches to problems and
43         new features.
44
45         There are different areas of interest where high-level
46         contributions can be made:
47
48         <ul>
49         * <b>JIT compiler</b>: tasks can be: adding more optimizations, reducing 
50         compile time, porting to different architectures.
51
52         * <b>AOT compiler</b>: optimizing the compiler output and the AOT loader,
53         better support for multiple application domains.
54         
55         * <b>VM runtime</b>: optimizing the runtime data structures, experimenting with
56         different garbage collectors, integration with different component models.
57         
58         * <b>Class library</b>: many opportunities in the implementation of regular 
59         expressions, Xml related technologies (XPath, XLST, etc).
60
61         * <b>Compilers</b>: writing compilers, interpreters and runtimes for langauges
62         so that they run on the CLR (using Reflection.Emit support, for example).
63         </ul>
64
65 Happy hacking!
66
67 <table border=1 cellspacing="0" cellpadding="0">
68         <tr>
69                 <th>Area<th>Description<th>Difficulty<th>Time estimate<th>Bugzilla ID
70         </tr>
71
72         <tr>
73                 <td>Runtime (mono/metadata)
74                 <td>Optimize method vtable. Currently all the methods in a class
75                 are added to the method vtable, including static and non-virtual methods.
76                 This makes vtables bigger and the instructions to access them are longer, 
77                 increasing also code size. Some code in metadata/icall.c and maybe also some 
78                 remoting code may depend on the current layout: such code should be fixed as well.
79                 <td>Medium
80                 <td>1-2 weeks
81                 <td>not assigned
82         </tr>
83
84         <tr>
85                 <td>System assembly (mcs/class/System/)
86                 <td>Implement the IL-based regular expression engine. Instead of
87                 intepreting the regular expression pattern, a method is created at runtime using
88                 Reflection.Emit. This makes for faster pattern matching because there is no 
89                 intepreter overhead and the matching code is jitted to fast native code.
90                 Bonus points if the compiled regular expression is compatible with the ones generated 
91                 by the MS runtime.
92                 <td>Medium-hard (thesis subject)
93                 <td>2-4 months
94                 <td>not assigned
95         </tr>
96
97         <tr>
98                 <td>JIT (mono/mini/)
99                 <td>Implement common subexpression elimination.
100                 Global and local common subexpression elimination needs to be implemented
101                 to achieve better performance. The local case is easier and may take just one month.
102                 It should be implemented in the context of the SSA framework (mini/ssa.c).
103                 <td>Hard (thesis subject)
104                 <td>2-4 months 
105                 <td>not assigned
106         </tr>
107
108         <tr>
109                 <td>JIT (mono/mini/)
110                 <td>Optimize AOT compiler output.
111                 Currently the code generated by the AOT compiler may be significantly slower than
112                 jitted code. This is mostly because the AOT code supports multiple application domains
113                 and some values that are constant at JIT-time are not constant at AOT-time. It may be
114                 needed to write a simple dynamic linker and/or binary object writer. Bonus poinst if
115                 it supports ELF, PE/COFF and mach-O binary formats. A possible idea for improvements 
116                 is also the use of appdomain ID-indexed tables to get at the appdomain specific data.
117                 <td>Medium-hard (thesis subject)
118                 <td>3-6 months
119                 <td>not assigned
120         </tr>
121
122         <tr>
123                 <td>JIT (mono/mini/)
124                 <td>Implement generics support.
125                 We need to add support for the additional instructions and change existing ones to
126                 support the generics requirements.
127                 <td>Medium-hard
128                 <td>2-3 months
129                 <td>not assigned
130         </tr>
131
132         <tr>
133                 <td>JIT (mono/mini/)
134                 <td>Port the JIT to additional architectures.
135                 Currently ports are in the works for ppc, arm, sparc, s390. None of the ports
136                 are as feature-complete as the x86 one, yet, so help is needed in getting them
137                 up to speed. Ports to more architectures are welcome as well.
138                 <td>Medium-hard
139                 <td>3-6 months per arch
140                 <td>not assigned
141         </tr>
142
143         <tr>
144                 <td>Runtime and JIT (mono/metadata and mono/mini/)
145                 <td>Add support for COM and/or XPCOM and/or ORBit.
146                 We need a way to seamlessy use existing component technologies inside the mono runtime.
147                 The COM support needs to match the MS runtime behaviour and is targeted at windows systems.
148                 XPCOM and ORBit support are important on Unix platforms. Bonus points for developing
149                 the runtime support so that different component systems can be used at the same time.
150                 <td>Medium-hard (thesis subject)
151                 <td>3-4 months for each
152                 <td>not assigned
153         </tr>
154
155         <tr>
156                 <td>Runtime and JIT (mono/metadata and mono/mini/)
157                 <td>Implement support for Code Access Security.
158                 Support needs to be added to the JIT and the runtime to ensure
159                 code that executes privileged operations is permitted to do so.
160                 The task includes loading the security information from metadata,
161                 collecting evidence, inserting calls to the permission objects, 
162                 stack walking to collect security info.
163                 <td>Medium-hard (thesis subject)
164                 <td>4-5 months
165                 <td>not assigned
166         </tr>
167
168         <tr>
169                 <td>Runtime and JIT (mono/metadata and mono/mini/)
170                 <td>Implement support for a generational GC.
171                 We're currently using a conservative non-moving GC.
172                 Support for a generational and moving GC requires changes to the JIT
173                 (to record locations in frames as well as registers that may contain 
174                 pointers to GC-allocated memory) and to the runtime code (when
175                 objects are manipulated directly we should make sure they are pinned
176                 and reachable by the GC also in the C unmanaged code). Code from an existing
177                 precise GC such as the ORP one could be reused or a new GC may be developed
178                 (increasing the estimated development time).
179                 <td>Hard (thesis subject)
180                 <td>6-8 months
181                 <td>not assigned
182         </tr>
183
184         <tr>
185                 <td>Compilers for dynamic languages
186                 <td>Write a IL compiler and runtime support for dynamic languages like
187                 Python, Perl, Ruby, PHP.
188                 <td>Medium-hard (thesis subject)
189                 <td>6-12 months
190                 <td>not assigned
191         </tr>
192
193 </table>
194