Array Size Limitations Overcome!

From: David McClain (dmcclain@azstarnet.com)
Date: Sun Jan 31 1999 - 06:59:55 MET


From: "David McClain" <dmcclain@azstarnet.com>
To: "Liste CAML" <caml-list@inria.fr>
Subject: Array Size Limitations Overcome!
Date: Sat, 30 Jan 1999 22:59:55 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01BE4CA4.40DE98B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have just finished developing a layer called "General_Array" on top of =
the "Array" library that permits unlimited sized arrays (up to 2^30 =
elements). I do it by noting that Array.unsafe_get and Array.unsafe_set =
cannot distingish an actual heap object from a user allocated pointer to =
doubles. By puling some stunts in C I can make OCAML deal with this =
"arena" in a uniform manner between arrays of floats and my own large =
arrays. Hence the same code writtin with the Array.unsafe_get/set works =
with either one, and I simply build my own arrays when the size would =
exceed the limits imposed by OCAML.

Note that the "alloc_final" function allows me to allocate my own large =
structures, and even though they appear as only a single heap word to =
OCAML, I can sensitize OCAML to my large allocations and force a more =
frequent GC cycle to help keep these foreign objects from overwhelming =
the paging system.

I will clean up the code and post it on my Web site shortly. I must say, =
that this was what I consider a major architectural change to the =
underpinnings of my OCAML image processing library. And yet, in spite of =
this major shift, the OCAML code worked perfectly well. I have never =
seen anything like it! I did have one bug in my "C" code (a simple =
3-letter typo), but the OCAML stuff was pristine!

David McClain
Sr. Scientist
Raytheon Missile Systems Co.
Tucson, AZ
http://www.azstarnet.com/~dmcclain/homepage.htm



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:19 MET