[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