[Mono-list] the System.String rewrite

[Joe Tennies]

I'd take this if it's still available in a week.  I'm a little busy
between now and then.

If someone wants to work on this, go right ahead and take it.  There's
plenty to go around ;)

On Fri, 2002-02-22 at 13:13, Paolo Molaro wrote:
> Anyone with lots of spare cycles? Read on.
> 
> Basically, a string needs to be represented as a contiguus chunk of
> memory (at the time I proposed this it was for performance/memory usage
> reasons, but it turns out that this is required by the implementation).
> 
> The current String.cs code has done his duty, but it's time to replace
> it. It basically needs to go through the same set of changes that I did 
> for the array representation a few months ago. I haven't tackled the
> work for string, because its a big task and, after patching it here and 
> there, the current code somewhat works.
> 
> So, here is how a string appears now (as a C structure):
> 
> 	struct MonoString {
> 		MonoObject obj;
> 		int length;
> 		MonoArray *c_str;
> 	};
> 
> MonoArray is:
> 	struct MonoArray {
> 		MonoObject obj;
> 		int length;
> 		double data [0];
> 	}
> 
> Note the size of the data array: since arrays are fixed sized, when we
> allocate the object, we also reserve room for length items in the array
> (the type double is used only for alignment reasons).
> 
> The string representation needs to become something like:
> 
> 	struct MonoString {
> 		MonoObject obj;
> 		int length;
> 		guint16 chars [0];
> 	};
> 
> This works just as well as for arrays: we allocate the object in one
> chunk (note that strings are immutable, hence fixed size as well).
> 
> This also means that the char array is not directly accessible from C#
> and as such, most of String.cs is useless :-(. We need to design the
> interface and have the C# code do argument checking and then call an
> internalcall in the runtime that will do all the work.
> Some code will need to change in the runtime as well, but mostly in
> metadata/object.c.
> 
> As you see, it's a big task, I think at least a full week of work,
> but someone will have to do it ;-) The advantage will be: higher speed,
> lower memory usage an eternal glory! (uhm, maybe not:-).
> So, any help with this is appreciated!
> 
> Thanks!
> 
> lupus
> 
> -- 
> -----------------------------------------------------------------
> lupus@debian.org                                     debian/rules
> lupus@ximian.com                             Monkeys do it better
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>