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 SAA10063 for caml-red; Thu, 14 Dec 2000 18:59:59 +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 NAA22749 for ; Tue, 12 Dec 2000 13:18:35 +0100 (MET) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eBCCIYX01775 for ; Tue, 12 Dec 2000 13:18:34 +0100 (MET) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id NAA0000008710; Tue, 12 Dec 2000 13:18:34 +0100 (MET) Date: Tue, 12 Dec 2000 13:18:34 +0100 (MET) From: Damien Doligez Message-Id: <200012121218.NAA0000008710@beaune.inria.fr> To: caml-list@inria.fr Subject: Re: fancy GC question Sender: weis@pauillac.inria.fr >From: Markus Mottl >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. > int *ar = (int *) &Field(v_ar, 0); >But is this really always safe if only C writes to the array? What about >e.g. heap compactions and other GC-actions? Can other effects mess up the >fact that the pointers map continuously on a contiguous chunk of memory >(of integers)? 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. >If yes, this would, of course, require the traditional use of the >"Field"-macro for every access. Otherwise, one could squeeze out a bit >more performance in some (probably rare) cases. Make sure you really need that performance and understand the maintenance cost before using such tricks. -- Damien