[Mono-dev] How To Convince Mono To Allocate Big Arrays

[Luis F. Ortiz]

On May 7, 2008, at 10:50 PM, Rodrigo Kumpera wrote:
> Hi Luis,
>
> To have your patch integrated, some changes are needed. First, we  
> want to default to 32bits sized arrays on 64bits machines, so your  
> changes must be conditionally compiled. To help with that some  
> changed to your patch are due. Next are some comments about it:
>
> Instead of replacing guint32 for gsize, it's better to create a new  
> type, let's say array_size_t. This would reduce conditional  
> compilation to fewer places.

Rodrigo:
	Permit me to reply to your message in parts, so that I clear on what  
needs to be done, from your point of view.

1) Add support for a new configuration argument to configure.in  
(AC_ARG_ENABLE(big-arrays,[ --enable-bug-arrays Enable allocation and  
indexing of arrays > 31 bits in size.],...))
2) Add a compile time define (AC_DEFINE(BIG_ARRAYS,1,[Enable  
allocation and indexing of arrays > 31 bits in size.]))
3) Use said compile time define to typedef array_size_t to either  
guint32 or guint64 depending on the state of BIG_ARRAYS in object.h
4) Use array_size_t where I used gsize in my patch.

Questions:

A) Do you agree then that the correct size types are either guint32 or  
guint64?
    Or would gint32 and gint64 be better choices as they would agree  
with the input arguments to ves_icall_System_Array_CreateInstanceImpl  
functions and the usage in socket-io.c?

B) Should the CreateInstanceImpl64 method definition in icall-def.h  
exist if BIG_ARRAYS is not defined.

C) In the case where BIG_ARRAYS is not defined,  should  
ves_icall_System_Array_CreateInstanceImpl64() still exist and make  
sure all arguments fit into the small guint32?

D) mono_array_size_t or array_size_t?   Without the mono prefix, i  
fear that some third-party library might also use the obvious name.   
Should the BIG_ARRAYS definition also use a MONO_ prefix?

/Ortiz/Luis