From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5766A7F7AF for ; Tue, 6 Oct 2015 17:10:16 +0200 (CEST) IronPort-PHdr: 9a23:sdw1SRNk/jax6TyL5GEl6mtUPXoX/o7sNwtQ0KIMzox0KPT/rarrMEGX3/hxlliBBdydsKIYzbWP+PmwEUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35jxiLn5os2bSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskyJdwqE5nIGXi0p1D8OSyrC6hzhFN+lqCrxtsJ03i+XLcz/C7cuVmLxwb1sTUrHhT0LfwUl92XPj8V2iuoPoRSvoDRwzpTYJZqJM/5me6rbe5UWSDwSDY5qSyVdD9bkPMM0BO0bMLMd9tGlqg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.126.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CAAQBh4xNWm7t+49Reg3tuwAwXBoV9AoE1PBABAQEBAQEBARABAQEBAQYLCwkhLoIdggcBAQEDAVUkBQsLGC5XBhMJiB0MCb9IAQEBAQEBBAEBAQEehXiFeYRnJgeCLk+BMQWHOI5MfwKMFokMBJJeOII7FweBVm8BiD4BAQE X-IPAS-Result: A0CAAQBh4xNWm7t+49Reg3tuwAwXBoV9AoE1PBABAQEBAQEBARABAQEBAQYLCwkhLoIdggcBAQEDAVUkBQsLGC5XBhMJiB0MCb9IAQEBAQEBBAEBAQEehXiFeYRnJgeCLk+BMQWHOI5MfwKMFokMBJJeOII7FweBVm8BiD4BAQE X-IronPort-AV: E=Sophos;i="5.17,644,1437429600"; d="asc'?scan'208";a="149793006" Received: from mout.kundenserver.de ([212.227.126.187]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2015 17:10:15 +0200 Received: from office1.lan.sumadev.de ([88.69.138.237]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0MNQ45-1Zh26Q0Een-006yEn; Tue, 06 Oct 2015 17:10:15 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 6E3F6DC05D; Tue, 6 Oct 2015 17:10:13 +0200 (CEST) Message-ID: <1444144145.3571.18.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: "Richard W.M. Jones" Cc: caml-list@inria.fr Date: Tue, 06 Oct 2015 17:09:05 +0200 In-Reply-To: <20151006141625.GB20503@annexia.org> References: <20151006134341.GA20503@annexia.org> <20151006141625.GB20503@annexia.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kAALjEIQTbc9vG0IomLs" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:qw2+NF330z03NblHpq2/b2G+QVCgYKjGkMBN9L4X/NwE/ha8atj 4AVnxcppWgRy704AJgNM0sF8jJw4p4/sFgdGthuKWLhBnR0CyFwh4Z8uL3yfONVzrsGmbQW smml1q0p+Xpx9g0A9cpuVVaTTNn4OdTegabWJT9kWTul+OcjUVBLBaQCJnnsQA35eycdZlb XEMRPs4ygoMfYYBOqKEZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:L5B+PLAhIxo=:hxiO38DY4fjxjImoFrFaXV Ki7RPcY7/Pb6wjxVuVWtBjCB3/2885uXcTNntRjgT/dEmz4HqepwIjZhroBiHB8DkYLAK5ad7 thmG0NQYeW4YYr0OuEcj2sa037W6ckzcHiFd5EGeGiKfCarGVtIBY5eUjAqI7UlibbSmFrtIT 8GvL/eha2H99nZOhW/14cHSdrtgZ2LblGtjrGZuAxqs1EdEjtgdpOInETmForCd3Nv6k6rpva tIgPWruqZDo9hbe0HRkdTUCGBdpEIUVf3c1sajbJhY42nRS3EIjb4Kyd5WrGhKzeTPIp8Ee7m aWatmkVM81Jp7bF9sj3pkCwWThFZge3pe1yZP1xOOt3Dac1ynIAqXz9+tuWczgUeVvJu49mWp Yl5IOkixm9Ft7LlQtWbB52LX8+383sy67t3atZ0XxEmeH6/QoC5skkpWJ701RrIs0L5Z1Bjqn j3kEbRgtETX5flRumqxszT+ffXl8gh/R8ts95FVa4yv45Cgge1KLfpFvNCuGPsYimifLbXXCT qwQZJbeKfmhCEnqUEHruFNbEGBPCZ4DuXivEz3YtVyY3VEWhZ788B3FysqLhrpCHCEE+aRWds tIvhcKaVOiSOVoiVq+1wO88kWkdun3iFrPoCbyduIraq2DscPbZd9DuvKG4HfXX8DjJdDwOCP o9JCFzNuZ/jyKY8zkc+PJBCtPDgsW50Bi0nFD4/7yoC73t2P/jY3nYeGVKMVt03vVG68= Subject: Re: [Caml-list] Finding "lost" references to OCaml heap values --=-kAALjEIQTbc9vG0IomLs Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag, den 06.10.2015, 15:16 +0100 schrieb Richard W.M. Jones: > On Tue, Oct 06, 2015 at 02:43:42PM +0100, Richard W.M. Jones wrote: > >=20 > > I guess I have two questions: > >=20 > > (1) Is calling Gc.compact () guaranteed to call the finalizer of any > > object which is no longer reachable, under all circumstances? Or > > would there be some case where it wouldn't be called? > >=20 > > (2) I have a large mixed OCaml / C program[a] where somehow calling > > Gc.compact isn't calling the destructor of a (very) large object. > > Manual code inspection has not revealed anything so far -- > > superficially it appears we are not holding any references to the > > object. Is there any method / library / tool that can inspect the > > OCaml heap and find references to an object? >=20 > Always good to explain these things, because the act of explaining it > has allowed me to work out why (2) is happening now. >=20 > The reason is because I was registering a global root from the C heap > pointing to the handle, and of course this prevents the handle from > being unreferenced. >=20 > This does, however, raise another question: >=20 > (3) I want to have a C heap 'value' pointing to an OCaml value, in > such a way that if the OCaml value moves around, the C value gets > updated to point to the new location. I was using a global root > for this purpose, but it seems like global roots really have two > purposes: >=20 > (i) To keep the C value updated if the OCaml value moves. >=20 > (ii) To act as a global root, preventing the value from being freed. >=20 > Is there a "weak" global root, that has property (i) but not property (ii= )? There is nothing like that in the C API of the OCaml FFI. What you can do is to keep only a symbolic reference to the OCaml value from the C struct (i.e. if it is the k-th such value just store the number k). The mapping from k to the OCaml value can be done with a weak hash table. For finalizing this you need to use Gc.finalize. All in all this is quite complicated. I guess it's only worth it if the memory management really needs to be fully-automatic. Gerd > Rich. >=20 > --=20 > Richard Jones > Red Hat >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-kAALjEIQTbc9vG0IomLs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJWE+QRAAoJEAaM4b9ZLB5TEcQH/1BdAjd86fC3cHfvybC97sOo vmnQQcPmdwVmTVA9ccgeU7xnT2l3+26V8GmaoATVeFDEbApi1Cf9NpaLIllFkwm4 M68gZ7C5a21MC8FaXUi6FtZi9L/ytiuDt28MYzMKnzsUODyIztzfrau7z367w9Ax UwZDD67tD4GenNIjp8hHKLhlYjEdugnsIMJmdUZIK0yiCVvY7AoxoUWtc2xeqZ6w iu0k5b1j1F0n81kz2M5T99HWTGvUqfM0BQC/5SkoW8skRNCl7fyQLM00guMAsDcq GP0qDJL/X7RQ0Pr0I/B33rRzqty24ar1CFXV3mtyqXmZ5hQe8rswOm9bl+3Zgss= =4l64 -----END PGP SIGNATURE----- --=-kAALjEIQTbc9vG0IomLs--