Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Gripes with array
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-09 (12:31)
From: Damien Doligez <damien.doligez@i...>
Subject: Re: [Caml-list] Gripes with array
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 Archives:
Bug reports: FAQ:
Beginner's list: