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

Luis F. Ortiz LuisOrtiz at verizon.net
Fri May 23 18:10:33 EDT 2008


Rodrigo:
     Sorry for the delayed response, things got busy, and I did not  
notice your message.
Please go ahead and check in the parts that you feel most comfortable  
with, since I do not
have commit rights.   I'll adapt any further submissions against the  
next official cut.

    The changes I have made are to be released under the X11 license  
and I vouch that
I have talked to the appropriate people at my employer (Interactive  
Supercomputing) and
they agree as well to release this and any further contributions I  
make to Mono while
under their employ under the X11 license.   There, that ought to make  
everybody happy.

Luis F. Ortiz


On May 16, 2008, at 10:53 AM, Rodrigo Kumpera wrote:\
> Hi Luis,
>
> Most parts of your patch are ok to be commited. As I said before,  
> it's better to have separate patches to speed up the review. As you  
> get more changes in, it will ease your work on preparing patches and  
> will ease on tracking head changes.
>
> Right now I'm ok with the configure, mono_array_t and related  
> changes. These were easy to review and don't introduce any change in  
> behavior, so we can check-in then right now. The others requires  
> more testing from me and would be easier to both of us if done after.
> Do you mind cooking you a patch only with the ok parts.
>
> Remember that you need to either release these changes under the X11  
> license or have done some copyright assignment paperwork.
>
> Thanks,
> Rodrigo
>
>
>
> On Thu, May 8, 2008 at 8:21 PM, Luis F. Ortiz  
> <LuisOrtiz at verizon.net> wrote:
> On May 8, 2008, at 9:29 AM, Rodrigo Kumpera wrote:
> One important thing I forgot. If you break your patch into a few  
> smaller ones the review process will be a lot easier to every one  
> involved.
> The first one can introduce new types and configuration foo; then  
> other to fix codegen and Array methods and; at last, a bunch of  
> fixes to classlib issues -like sockets, file i/o and so on.
>
> Cheers,
> Rodrigo
>
> OK, here is another stab at the changes.
>
> This modifies the following files:
>        configure.in
>
>        mono/metadata/object.c
>        mono/metadata/object.h
>        mono/metadata/icall-def.h
>        mono/metadata/icall.c
>        mono/metadata/socket-io.c
>
> These files:
>  1) Add a new configuration option, --enable-big-arrays, which  
> defines conditionally defines MONO_BIG_ARRAYS in config.h,
>  2) Add in mono/metadata/object.h :
>  A) A new typedef for mono_array_size_t to be either guint32 or  
> guint64
>  B) A new #define for MONO_ARRAY_MAX_INDEX for the biggest valid  
> array index, i.e. G_MAXINTxx
>  C) A new #define for MONO_ARRAY_MAX_SIZE for the biggest valid  
> array allocation, i.e. G_MAXUINTxx
>  D) The above all controlled by MONO_BIG_ARRAYS
>  3) Modify the definitions of mono_array_new(),  
> mono_array_new_full(), and mono_array_new_specific() to match,
>  4) Modify the usages of those functions in the metadata directory  
> to match,
>  5) Add range checking in  
> ves_icall_System_Array_CreateInstanceImpl64 so it works with or  
> without MONO_BIG_ARRAYS,
>  6) Attempt to address all the mistakes you pointed out.
>
> These changes, in addition to the other changes I made, pass "make  
> check" with the exception of Tests.test_0_regress_75832(), as  
> previously confessed.
>
>
>
>
>
> /Ortiz/Luis
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080523/d3b96fb2/attachment-0001.html 


More information about the Mono-devel-list mailing list