On Sep 9, 2004, at 14:08, Basile Starynkevitch [local] wrote:

>    The header layout remains the same (so only 22 bits for size on 32
>    bits machine), but if the size is all bit ones, the block is
>    actually a fixed block, and the real array size is the word before
>    the header.

The real size would have to be after the header, not before it, because
you cannot store anything before the header.

> If you have a huge array of
> pointers, the garbage collector (even the minor one) has to scan the
> full array - and this scan is "atomic" in the sense that it is not
> interruptible (and I believe that designing a GC which incrementally
> scans big values by chunks is not trivial, given Ocaml GC performance
> needs).

The minor GC will never scan such a huge array because you won't find
it in the minor heap.  What you say is still true of the major GC.

> Regarding very big data structures, I tend to believe that they should
> be more organized than just a single monster array (hence the current
> array limits on 32 bits machine is a sensible tradeoff), even on 64
> bits irons. But I have no practical experience on these.

I fixed a bug in a camlp4 lexer recently, where it needed an
(extensible) array larger than 16 million entries.  Implementing an
array of arrays increased the code size by as much as 6 lines...

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners