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 TAA19024 for caml-red; Thu, 14 Dec 2000 19:12:43 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA27237 for <caml-list@pauillac.inria.fr>; Tue, 12 Dec 2000 16:38:42 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eBCFcef09910;
	Tue, 12 Dec 2000 16:38:40 +0100 (MET)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA24191; Tue, 12 Dec 2000 16:38:40 +0100 (MET)
Date: Tue, 12 Dec 2000 16:38:39 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: fancy GC question
Message-ID: <20001212163839.B26381@pauillac.inria.fr>
References: <20001212040549.A5381@miss.wu-wien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20001212040549.A5381@miss.wu-wien.ac.at>; from mottl@miss.wu-wien.ac.at on Tue, Dec 12, 2000 at 04:05:50AM +0100
Sender: weis@pauillac.inria.fr

> When I allocate an integer array in OCaml, which is always boxed, both
> the pointers to and the elements are obviously contiguous in memory.
> One could exploit this in C-interfaces under the restriction that the
> array is never changed by the OCaml-runtime, e.g.:
> 
>   int *ar = (int *) &Field(v_ar, 0);
> 
> And then one can read/write directly into the integer array without
> having to follow an indirection (an intermediate pointer) by treating
> "ar" as a normal C array.
> 
> But is this really always safe if only C writes to the array?

It is safe if the C code does not perform any allocation in the Caml
heap while it is using the "ar" pointer.  An allocation can trigger a
garbage collection, which can move the Caml block denoted by "v_ar";
after this, the "ar" pointer no longer points inside the block!

(If "v_ar" is registered as a local root with the garbage collector,
its value will be updated after the GC to reflect the new address of
the block; however, the GC has no mechanism for updating derived
pointers such as "ar" in your example.)

But, yes, this is a safe trick to use in e.g. a tight loop that does
not allocate in the Caml heap.

> Can other effects mess up the
> fact that the pointers map continuously on a contiguous chunk of memory
> (of integers)?

I'm not sure I understand the question, but the various "fields" of a
Caml block (as accessed with the Field macro) are always contiguous in
memory.

- Xavier Leroy