From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA08416 for caml-red; Fri, 15 Dec 2000 13:54:28 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA01352 for ; Thu, 14 Dec 2000 23:10:34 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eBEMAXL04772 for ; Thu, 14 Dec 2000 23:10:33 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id XAA29162 for caml-list@inria.fr; Thu, 14 Dec 2000 23:10:33 +0100 (MET) Date: Thu, 14 Dec 2000 23:10:33 +0100 From: Markus Mottl To: OCAML Subject: Re: fancy GC question Message-ID: <20001214231033.A31107@miss.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: weis@pauillac.inria.fr On Tue, 12 Dec 2000, Damien Doligez wrote: > >When I allocate an integer array in OCaml, which is always boxed, both > >the pointers to and the elements are obviously contiguous in memory. > > There's no pointer in an integer array. Ok, they are actually not boxed but tagged (= no pointer) - sorry for the confusion. > Heap compaction can move the array and break your code (unless you > make sure to reset your ar variable after each compaction). Future > versions of the GC may move the array under other circumstances. And > if your array is small enough and was allocated in the minor heap, > then the minor GC will move it too. So (as Xavier mentioned) I have to make absolutely sure that no allocation can happen during manipulation of the array in C. > Make sure you really need that performance and understand the > maintenance cost before using such tricks. In fact, this piece of code had been in use in the PCRE since the very beginning without ever causing problems. It is only now that I discovered that I should better ask whether this is really safe: there is indeed no allocation there so I can leave it as is and safe the allocation of an extra array for C, which would otherwise add quite a bit of overhead in the C-interface. Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl