Added hackers TODO list.

svn path=/trunk/mono/; revision=15764

1 files changed, 178 insertions, 0 deletions

diff --git a/web/mono-todo b/web/mono-todo
new file mode 100644
index 00000000000..4555cb1c0bb
--- /dev/null
+++ b/web/mono-todo
@@ -0,0 +1,178 @@
+<h2>Mono hacking TODO list</h2>
+
+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:<br>
+<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.<p>
+The estimated time to complete any of the tasks is between 1 week to several months
+to accomodate for different hacking possibilities.<br>
+
+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:-).<p>
+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.<p>
+
+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.<p>
+There are different areas of interest where high-level contributions can be made:
+<ul>
+	<li><b>JIT compiler</b>: tasks can be: adding more optimizations, reducing 
+	compile time, porting to different architectures.
+	<li><b>AOT compiler</b>: optimizing the compiler output and the AOT loader,
+	better support for multiple application domains.
+	<li><b>VM runtime</b>: optimizing the runtime data structures, experimenting with
+	different garbage collectors, integration with different component models.
+	<li><b>Class library</b>: many opportunities in the implementation of regular 
+	expressions, Xml related technologies (XPath, XLST, etc).
+	<li><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!<p>
+
+<table border=1 cellspacing="0" cellpadding="0">
+	<tr>
+		<th>Area<th>Description<th>Difficulty<th>Time estimate<th>Bugzilla ID
+	</tr>
+
+	<tr>
+		<td>Runtime (mono/metadata)
+		<td>Optimize method vtable. Currently all the methods in a class
+		are added to the method vtable, including static and non-virtual methods.
+		This makes vtables bigger and the instructions to access them are longer, 
+		increasing also code size. Some code in metadata/icall.c and maybe also some 
+		remoting code may depend on the current layout: such code should be fixed as well.
+		<td>Medium
+		<td>1-2 weeks
+		<td>not assigned
+	</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>not assigned
+	</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>Implement generics support.
+		We need to add support for the additional instructions and change existing ones to
+		support the generics requirements.
+		<td>Medium-hard
+		<td>2-3 months
+		<td>not assigned
+	</tr>
+
+	<tr>
+		<td>JIT (mono/mini/)
+		<td>Port the JIT to additional architectures.
+		Currently ports are in the works for ppc, arm, sparc, s390. None of the ports
+		are as feature-complete as the x86 one, yet, so help is needed in getting them
+		up to speed. 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>not assigned
+	</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>
+
+</table>
+