From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1AA8A7EEBF for ; Tue, 7 Jul 2015 02:32:31 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=pra; client-ip=138.231.136.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=mailfrom; client-ip=138.231.136.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@redisdead.crans.org designates 138.231.136.39 as permitted sender) identity=helo; client-ip=138.231.136.39; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="postmaster@redisdead.crans.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DAAwBjHZtVYyeI54pCGg6DBFRgAYMevDWFdwKBQEwBAQEBAQEHGBUGUYQkAQEEI1URCw4KAgIFFAILAgIJAwIBAgFFBgEMCAKIKgQJOrN9lm8BAQEBBgEBAQEBHYEhiiqFDYJogUMBBJQVhGKIQESGPow9g12DY0BtAYJKAQEB X-IPAS-Result: A0DAAwBjHZtVYyeI54pCGg6DBFRgAYMevDWFdwKBQEwBAQEBAQEHGBUGUYQkAQEEI1URCw4KAgIFFAILAgIJAwIBAgFFBgEMCAKIKgQJOrN9lm8BAQEBBgEBAQEBHYEhiiqFDYJogUMBBJQVhGKIQESGPow9g12DY0BtAYJKAQEB X-IronPort-AV: E=Sophos;i="5.15,418,1432591200"; d="scan'208";a="169099731" Received: from redisdead.crans.org ([138.231.136.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 07 Jul 2015 02:32:30 +0200 Received: from [192.168.0.164] (abo-251-238-68.guy.modulonet.fr [85.68.238.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by redisdead.crans.org (Postfix) with ESMTPSA id 3BB94B11; Tue, 7 Jul 2015 02:32:30 +0200 (CEST) Message-ID: <559B1E1D.8010501@ocamlpro.com> Date: Tue, 07 Jul 2015 02:32:29 +0200 From: Pierre Chambart Organization: OcamlPro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Michael Hicks , caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Validation-by: pierre.chambart@ocamlpro.com Subject: Re: [Caml-list] Scanning objects outside the OCaml heap On 07/07/2015 00:21, Michael Hicks wrote: > > I'm interested in implementing a custom memory management strategy > that I can prove is safe in a language I will compile to OCaml. I'm > thinking I'd like to allocate freeable memory outside the OCaml heap, > but as OCaml values. Since these values can point to OCaml > heap-resident data, they need to be scanned. But I don't want to have > to explicitly register/deregister them as roots to the GC, or track > all mutations to the values, if I can help it. Rather, having a single > "persistent root" to my memory area, for purposes of scanning, would > be ideal. > > Thanks in advance for any help, There is an undocumented and unexported way to do something like that: the caml_scan_roots_hook. You can register a callback in this global variable that takes a scanning action (another callback) to call on every of your roots. See https://github.com/ocaml/ocaml/blob/trunk/byterun/caml/roots.h#L34 for the definition and https://github.com/ocaml/ocaml/blob/trunk/asmrun/roots.c#L270 as an example of how the scanning action should be called. Since those roots are scanned only at the end of a gc major cycle, you must handle mutation specificaly (like mutations in the major heap). You will have to track them as you must not have unnoticed pointers from outside of the minor heap to the minor heap. You will have to addapt caml_modify as it suppose that values not in the minor are in the major heap. Since it is declared using a weak symbol, this can be redefined without changing the runtime. See http://caml.inria.fr/mantis/view.php?id=6084 . Take care, as this is not exported in the official interface, this could break at any version change of the runtime. Have fun with your potential hard to debug segfaults ;) -- Pierre