[Mono-devel-list] How to handle huge string collation resources?

[Ben Maurer]

On Wed, 2005-06-22 at 04:26 +0900, Atsushi Eno wrote:
> 	3. run "make". It will automatically downloads some files
> 	   from some sites. For now without this step the build
> 	   b0rks.

Of course, this will need to be changed ;-).



> Here is a serious problem. In step 3 it makes 1.2MB of a C#
> source file that results in 500KB increase of mscorlib.dll.

If you are generating a file in C#, you are going to be managing memory
badly. C# has no sense of a const array. When you say:

static readonly int [] x = {
	...
}

This array is actually allocated in the GC *at runtime*.

Doing it in a header file would be an option. Not really ideal because
it gets into our package three times (once for the statically linked
mono binary, another for libmono.so, another for libmono.a).

The best option is to have it as a resource in a dll. The runtime memory
maps that.

> And for about 200KB of data, they are just for CJK cultures
> so they won't be used unless we use those cultures to handle
> culture-sensitive CJK collation. That is mostly waste of memory.

Not if the data doesn't get paged in ;-).

> 	- CompareInfo or whatever holds those tables as static
> 	  variables.
> 	- If the variable is null, then it tries to load the
> 	  "internally stored table" via runtime icall_1. However
> 	  at this stage it returns null, since nothing is stored.
> 	- Then, CompareInfo or whatever loads "table-only assembly"
> 	  via reflection and loads table into memory, and
> 	  then invokes an icall_2 that sets the table as runtime
> 	  internal table.
> 	- Next time CompareInfo tries to fill the table, icall_1
> 	  will return the table.

The memory system essentially does that via the mmap call, however it is
hidden from view.

-- Ben