[Mono-dev] Big Arrays, Many Changes --- Request for Advice

[Luis F. Ortiz]

Jonathan:
      Sorry for the delay in my response; first off, the test  
application I wrote was buggy and lied about how much memory was  
being allocated.   I had to rewrite it.  It now clearly can not  
allocate arrays larger than 2GB, though I have yet to pin down the  
exact amounts, as it seems that my test program gives me numbers that  
are different, depending on which C# compiler I use (csc or mcs) and  
the CLR in use under XP64.

      I'll get down to the bottom of this and reply later.

--Luis

On Sep 3, 2007, at 5:26 PM, Jonathan Chambers wrote:
> Hello,
>
> I don't have an answer to your problem, but I did have another  
> question. I can't find a link to the documentation in msdn, but I  
> thought arrays were limited to 2 GB in the .Net runtime (even on 64- 
> bit). Do you not see this behavior?
>
> http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
>
> Thanks,
> Jonathan
>
> On 9/3/07, Luis F. Ortiz <LuisOrtiz at verizon.net> wrote:
> Folks:
>
> I was porting a small test application that was written in C# that
> allocated
> an array with a large number of elements (> 2^32).  While it
> compiled and ran
> in Visual Studio's C# under WindowsXP-64bit without a hitch, when I
> compiled
> and ran it under mcs/mono (1.2.4) on the same hardware, but booted up
> under
> Fedora7-x86_64, I ran into a few problems.
>
> Digging into it a bit, I discovered that:
>
> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
> which does not seem
>      to be the case as far as ECMA-335v4.
> 2)  MONO assumes that array lengths and bounds can always be
> represented as guint32's,
>      [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ]
>
>
> Would folks object to a series of patches to:
>
> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
> OpCodes.Conv_Ovf_U4/I4
>      for array size arguments,
> B)  Modify mono/metadata/object.h to change the base type for array
> lengths/bounds to
>      XXX instead of guint32,
> C)  Change mono/metadata/object.c to change the functions that create/
> access arrays to
>      take XXX instead of guint32 length/bounds arguments.  Also
> perhaps update some of
>      the lower level object allocation functions to use XXX as needed.
> D)  Modify the execution of NEWARR be able to deal with I/U native
> types.  No doubt something
>      in the JIT needs tweaking as well.
> E)  Double check that array indexing not only takes native int types,
> but uses them right.
> F)  Add a few new test cases for large array allocation.
> G)  Whatever else needs to be done that I'll bump into after I try
> making the above changes
>      and realize what I forgot.  Warnings of known hazards gratefully
> accepted.
>
> My big question is what the right type for the size ought to be?
> I've seen int, size_t, gsize,
> and guint32 used in Mono.  I suspect that int and guint32 are wrong
> from a portability perspective,
> but would prefer that someone more intimately involved with Mono to
> say if guint or gsize or size_t
> were preferred. I'm guessing Bug 81774 is related to this as well.
>
> BTW, is this too big for a newby to tackle?
>
> --Luis F. Ortiz
> Follower of the "Selfish Way"
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

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