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         <li> Write documentation.
   8         <li> Write regression tests.
   9         <li> Complete the implementations of the class libraries.
  10         <li> 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>System assembly (mcs/class/System/)
  74                 <td>Implement the IL-based regular expression engine. Instead of
  75                 intepreting the regular expression pattern, a method is created at runtime using
  76                 Reflection.Emit. This makes for faster pattern matching because there is no
  77                 intepreter overhead and the matching code is jitted to fast native code.
  78                 Bonus points if the compiled regular expression is compatible with the ones generated
  79                 by the MS runtime.
  80                 <td>Medium-hard (thesis subject)
  81                 <td>2-4 months
  82                 <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52605">52605</a>
  83         </tr>
  84
  85         <tr>
  86                 <td>JIT (mono/mini/)
  87                 <td>Implement common subexpression elimination.
  88                 Global and local common subexpression elimination needs to be implemented
  89                 to achieve better performance. The local case is easier and may take just one month.
  90                 It should be implemented in the context of the SSA framework (mini/ssa.c).
  91                 <td>Hard (thesis subject)
  92                 <td>2-4 months
  93                 <td>not assigned
  94         </tr>
  95
  96         <tr>
  97                 <td>JIT (mono/mini/)
  98                 <td>Optimize AOT compiler output.
  99                 Currently the code generated by the AOT compiler may be significantly slower than
 100                 jitted code. This is mostly because the AOT code supports multiple application domains
 101                 and some values that are constant at JIT-time are not constant at AOT-time. It may be
 102                 needed to write a simple dynamic linker and/or binary object writer. Bonus poinst if
 103                 it supports ELF, PE/COFF and mach-O binary formats. A possible idea for improvements
 104                 is also the use of appdomain ID-indexed tables to get at the appdomain specific data.
 105                 <td>Medium-hard (thesis subject)
 106                 <td>3-6 months
 107                 <td>not assigned
 108         </tr>
 109
 110         <tr>
 111                 <td>JIT (mono/mini/)
 112                 <td>Implement generics support.
 113                 We need to add support for the additional instructions and change existing ones to
 114                 support the generics requirements.
 115                 <td>Medium-hard
 116                 <td>2-3 months
 117                 <td>lupus and Martin
 118         </tr>
 119
 120         <tr>
 121                 <td>JIT (mono/mini/)
 122                 <td>Port the JIT to additional architectures.
 123                 Currently ports are in the works for mips, arm, sparc, s390. None of the ports
 124                 are as feature-complete as the x86 one, yet, so help is needed in getting them
 125                 up to speed. Ports to more architectures are welcome as well.
 126                 <td>Medium-hard
 127                 <td>3-6 months per arch
 128                 <td>not assigned
 129         </tr>
 130
 131         <tr>
 132                 <td>Runtime and JIT (mono/metadata and mono/mini/)
 133                 <td>Add support for COM and/or XPCOM and/or ORBit.
 134                 We need a way to seamlessy use existing component technologies inside the mono runtime.
 135                 The COM support needs to match the MS runtime behaviour and is targeted at windows systems.
 136                 XPCOM and ORBit support are important on Unix platforms. Bonus points for developing
 137                 the runtime support so that different component systems can be used at the same time.
 138                 <td>Medium-hard (thesis subject)
 139                 <td>3-4 months for each
 140                 <td>not assigned
 141         </tr>
 142
 143         <tr>
 144                 <td>Runtime and JIT (mono/metadata and mono/mini/)
 145                 <td>Implement support for Code Access Security.
 146                 Support needs to be added to the JIT and the runtime to ensure
 147                 code that executes privileged operations is permitted to do so.
 148                 The task includes loading the security information from metadata,
 149                 collecting evidence, inserting calls to the permission objects,
 150                 stack walking to collect security info.
 151                 <td>Medium-hard (thesis subject)
 152                 <td>4-5 months
 153                 <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52606">52606</a>
 154         </tr>
 155
 156         <tr>
 157                 <td>Runtime and JIT (mono/metadata and mono/mini/)
 158                 <td>Implement support for a generational GC.
 159                 We're currently using a conservative non-moving GC.
 160                 Support for a generational and moving GC requires changes to the JIT
 161                 (to record locations in frames as well as registers that may contain
 162                 pointers to GC-allocated memory) and to the runtime code (when
 163                 objects are manipulated directly we should make sure they are pinned
 164                 and reachable by the GC also in the C unmanaged code). Code from an existing
 165                 precise GC such as the ORP one could be reused or a new GC may be developed
 166                 (increasing the estimated development time).
 167                 <td>Hard (thesis subject)
 168                 <td>6-8 months
 169                 <td>not assigned
 170         </tr>
 171
 172         <tr>
 173                 <td>Compilers for dynamic languages
 174                 <td>Write a IL compiler and runtime support for dynamic languages like
 175                 Python, Perl, Ruby, PHP.
 176                 <td>Medium-hard (thesis subject)
 177                 <td>6-12 months
 178                 <td>not assigned
 179         </tr>
 180
 181         <tr>
 182                 <td>Tools
 183                 <td>Write an implementation of the MSBuild compilation tool available in .NET 1.2
 184                 <td>Medium
 185                 <td>4-6 months
 186                 <td>not assigned
 187         </tr>
 188         <tr>
 189                 <td>Build tools.
 190                 <td>Currently it is easy for people doing daily
 191                 updates from CVS to break their installation.  Design a mechanism by
 192                 which Mono never fails to compile.
 193                 <td>Easy
 194                 <td>1-2 weeks
 195                 <td>not assigned
 196         </tr>
 197         <tr>
 198                 <td>Documentation.
 199                 <td>Editorial review of the Monkeyguide: The monkeyguide is known to contain outdated
 200                 statements, it needs to be reviewed and it needs an
 201                 editor to take control over it.  Some simple tasks
 202                 include flattening out the Monkeyguide, since it is
 203                 too nested today.
 204                 <td>Easy
 205                 <td>Ongoing work.
 206                 <td>not assigned
 207         </tr>
 208         <tr>
 209                 <td>Documentation
 210                 <td>GNOME.NET Chapter should probably be separated
 211                 from the Monkeyguide.  This is probably the most
 212                 complete chapter, but it is burried  in various nested
 213                 levels of stuff, and because of this, it is not being
 214                 updated.  Write a chapter on custom control
 215                 authoring and common patterns of app development.
 216                 <td>Easy
 217                 <td>Ongoing work.
 218                 <td>not assigned
 219         </tr>
 220         <tr>
 221                 <td>Documentation Tools
 222                 <td>The Monodoc collaborative service needs a better
 223                 administration tool than it has today;  Someone needs
 224                 to redo the UI and streamline its process.
 225                 <td>Easy
 226                 <td>2-3 months.
 227                 <td>not assigned
 228         </tr>
 229         <tr>
 230                 <td>Comment Service API
 231                 <td>Design a full system for comments and ratings so
 232                 people can annotate the documentation in Monodoc.
 233                 <td>Easy
 234                 <td>2-3 months.
 235                 <td>not assigned
 236         </tr>
 237         <tr>
 238                 <td>POSIX bindings.
 239                 <td>The Mono.POSIX assembly is a project to create a binding to
 240         the various low-level calls in Unix which are not available
 241         thought he regular assemblies in .NET.
 242
 243         The work should be done in two steps: one step is doing the
 244         low-level binding for the system call, and another possibly is
 245         to expose .NET-level objects like Streams for common patterns:
 246         for example Streams for socketpairs.
 247
 248         <ul>
 249                 <li>Complete the bindings for all POSIX calls in Mono.Posix.
 250         </ul>
 251
 252                 <td>Medium
 253                 <td>2-3 months + QA.
 254                 <td>not assigned
 255         </tr>
 256         <tr>
 257                 <td>System.Drawing CODECs
 258                 <td>Complete the JPEG and PNG codecs to be fully
 259                 finished; Implement EXIF data loading; Implement the missing image codecs.
 260                 <td>Medium
 261                 <td>2-3 months.
 262                 <td>not assigned
 263         </tr>
 264         <tr>
 265                 <td>System.Data updates
 266                 <td>.NET 1.2 introduced many new updates to the
 267                 System.Data namespace: MARS and ObjectSpaces are the
 268                 big ones.
 269                 <td>Medium
 270                 <td>6-9 months.
 271                 <td>Work with the mono-devel-list to keep track of things.
 272         </tr>
 273 </table>
 274