web/mono-todo

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