On Wed, 14 Nov 2001, Marcin 'Qrczak' Kowalczyk wrote:
> I guess that it's fine to initialize an array of non-floats with
> 'Obj.magic 0' even if the type doesn't have nullary constructors,
> provided that I overwrite elements with valid objects before use?

Yes, this is safe for non-float arrays. The GC will only interpret some
array element as a pointer to follow if it is not tagged as integer
(or nullary constructor, which is the same representation). I abuse this
"feature" in my "Res"-module to implement automatically resizing arrays.

> I don't always have a proper element at hand. Is it true that the
> Array module cares to always find a valid element for initialization
> only because of float arrays?

There is no function that allows you to create an array without passing
an initial element in the Array-module. It would be nice if there
were a function that allows one to create uninitialized, unboxed float
arrays. This is easy to implement and could be useful for efficiency
purposes in some occasions. It's, of course, not possible for other
kinds of arrays, because the memory region might contain things that
look like a pointer to the GC.

Btw., wouldn't it be possible (or is this actually implemented - haven't
looked) that the GC allocates arrays of integers always within the same
region of memory? Then it could reuse this region as a pool for creating
uninitialized integer arrays. Only if there is not enough memory, more
would have to be allocated and initialized.

> Why are small arrays and large arrays treated differently?

I think this is part of the GC-strategy to gain efficiency. The heuristics
is that large arrays (or other large chunks of memory) are not likely
to be short-lived.

I hope my explanations were not too far from the truth... ;)

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr