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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id A2EED7F7AF for ; Tue, 6 Oct 2015 16:16:26 +0200 (CEST) IronPort-PHdr: 9a23:Q4hkyBxUMCikhyLXCy+O+j09IxM/srCxBDY+r6Qd0e4XIJqq85mqBkHD//Il1AaPBtWHra0dwLKI+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStKU0J38j7760qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGwD884mosVJVKG/e6UjUZRZCi4nOiY7/p7Frx7GGEG153AcW38a2iUOJk6Nzhb8U4y7+n/gt+F98CCcO8DmTLlyXi6tufQ4ACT0gTsKYmZquFrcjdZ92fpW Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=rich@annexia.org; spf=Pass smtp.mailfrom=rich@annexia.org; spf=None smtp.helo=postmaster@furbychan.cocan.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rich@annexia.org) identity=pra; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rich@annexia.org designates 80.68.91.176 as permitted sender) identity=mailfrom; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@furbychan.cocan.org) identity=helo; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="postmaster@furbychan.cocan.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQCD1hNW/7BbRFBerisFAQEBAQEBBQGBDZUshhoCgW4QAQEBAQEBAQGBCYIdgggBAQQ6TwsYCSUPBSiIZgG/IAErhiw+hQeFFBeDA4EUBZJNgzcBjQ6bdjgrhAM9iHIBAQE X-IPAS-Result: A0A0BQCD1hNW/7BbRFBerisFAQEBAQEBBQGBDZUshhoCgW4QAQEBAQEBAQGBCYIdgggBAQQ6TwsYCSUPBSiIZgG/IAErhiw+hQeFFBeDA4EUBZJNgzcBjQ6bdjgrhAM9iHIBAQE X-IronPort-AV: E=Sophos;i="5.17,644,1437429600"; d="scan'208";a="181377199" Received: from annexia.org (HELO furbychan.cocan.org) ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 06 Oct 2015 16:16:26 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.84) (envelope-from ) id 1ZjT2X-0005T5-Gu for caml-list@inria.fr; Tue, 06 Oct 2015 15:16:25 +0100 Date: Tue, 6 Oct 2015 15:16:25 +0100 From: "Richard W.M. Jones" To: caml-list@inria.fr Message-ID: <20151006141625.GB20503@annexia.org> References: <20151006134341.GA20503@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151006134341.GA20503@annexia.org> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Caml-list] Finding "lost" references to OCaml heap values On Tue, Oct 06, 2015 at 02:43:42PM +0100, Richard W.M. Jones wrote: > > I guess I have two questions: > > (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? > > (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? Always good to explain these things, because the act of explaining it has allowed me to work out why (2) is happening now. 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. This does, however, raise another question: (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: (i) To keep the C value updated if the OCaml value moves. (ii) To act as a global root, preventing the value from being freed. Is there a "weak" global root, that has property (i) but not property (ii)? Rich. -- Richard Jones Red Hat