Generic Code Sharing: Good and Bad News

Mark Probst has been working for the past few months on adding support to the Mono JIT to support generic code sharing. This is a technique that allows the JIT to share the same code generated for two differently instantiated types, for example:

	class Stack<T> {
	    T [] data = new T [10];
	    int top;
	
	    public void Push (T t) { data [top++] = t; }
	    public T    Pop  ()    { return data [--top]; }
	    public int  Count      { get { return top; } }
	}

	class Test {
		static void Main ()
		{
			Stack<long> ls = new Stack<long> ();
			ls.Push (10);
	
			Stack<Test> ts = new Stack<Test> ();
			ts.Push (new Test ());
	
			Console.WriteLine ("Count={0} {1}", ls.Count, ts.Count);
		}
	}
	

The JIT must generate different code for the actual Stack instantiation, one must contain a pointer (32 bits on 32 bit machines) and another one must contain 64 bits. So the structures are different in memory, and so is the implementation for Push and Pop.

But certain methods do not depend on the datatype sizes (for example) and could be shared regardless of how their container type is instantiated.

Mark posted the Good news, the bad news and his strategy to deal with the bad news. Am going to limit myself to the good news, and you can click on the link and read the thread for the bad news:

Now for some interesting statistics.  Apart from the runtime's test
suite I've used three other test suites/benchmarks, namely IronPython
(running pystone), Nemerle (compiling its own compiler) and FSharp
(compiling and running a Hello World program).  Here are the
Good-News-statistics.  The numbers given are "no sharing / sharing"
and have been collected on a 32 bit system:

IronPython
  Methods compiled: 3614 / 3368
  native code space used: 719k / 691k

Nemerle
  Method compiled: 7210 / 6302
  native code space used: 2001k / 1943k

FSharp
  Methods compiled: 15529 / 11431
  native code space used: 2193k / 2062k
	
	

See his post for the rest.

Update: Mark informs me that the "bad news" that I conveniently left out of this post (memory consumption in FSharp for bookkeeping was 600k of memory) has now been fixed.

The 600k of bookkeeping in the FSharp test has been now turned down to 14k. So we can scratch that "bad news" part. Congratulations Mark!