[Mono-dev] Big Arrays, Many Changes --- Request for Advice
Luis F. Ortiz
LuisOrtiz at verizon.net
Thu Sep 6 07:47:51 EDT 2007
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.
On Sep 3, 2007, at 5:26 PM, Jonathan Chambers wrote:
> 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?
> On 9/3/07, Luis F. Ortiz <LuisOrtiz at verizon.net> wrote:
> I was porting a small test application that was written in C# that
> 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
> and ran it under mcs/mono (1.2.4) on the same hardware, but booted up
> 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list