path: root/web/mono-todo

* 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>