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 512237FA56 for ; Thu, 24 Jul 2014 02:44:09 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jfc@MIT.EDU) identity=pra; client-ip=18.7.68.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="jfc@MIT.EDU"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jfc@mit.edu designates 18.7.68.34 as permitted sender) identity=mailfrom; client-ip=18.7.68.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="jfc@mit.edu"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@dmz-mailsec-scanner-5.mit.edu) identity=helo; client-ip=18.7.68.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="postmaster@dmz-mailsec-scanner-5.mit.edu"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsECAG9V0FMSB0QinGdsb2JhbABZ1RgBgQYWEAEBAQEBBg0JCRQphAQBBAE6PxALRjwbBohNCAO6CIZXFxiPMweERgEEmy2YJA X-IPAS-Result: AsECAG9V0FMSB0QinGdsb2JhbABZ1RgBgQYWEAEBAQEBBg0JCRQphAQBBAE6PxALRjwbBohNCAO6CIZXFxiPMweERgEEmy2YJA X-IronPort-AV: E=Sophos;i="5.01,720,1400018400"; d="scan'208";a="72601778" Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Jul 2014 02:44:08 +0200 X-AuditID: 12074422-f79be6d000007518-87-53d056d6d944 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.A9.29976.6D650D35; Wed, 23 Jul 2014 20:44:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6O0i6SD009473; Wed, 23 Jul 2014 20:44:06 -0400 Received: from atropos (pool-108-20-186-221.bstnma.fios.verizon.net [108.20.186.221]) (authenticated bits=0) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6O0i4lb023067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Jul 2014 20:44:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21456.22226.875151.670593@gargle.gargle.HOWL> Date: Wed, 23 Jul 2014 20:44:02 -0400 From: "John F. Carr" To: Raoul Duke Cc: OCaml In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> X-Mailer: VM 8.1.2 under 24.3.1 (amd64-portbld-freebsd10.0) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1r0ediHYYEuaxacdG1gsjk9+weTA 5LFz1l12j0kvDrEEMEVx2aSk5mSWpRbp2yVwZSz8fIelYBdPxfrZeQ2MXzi7GDk5JARMJF7e u80MYYtJXLi3nq2LkYtDSGA2k0TXpH9MEM5GRonTx6azg1QJCZxjkrhx1RzE5hUQlDg58wkL iM0soCVx499LJghbXmL72znMEDVWEqv+LgeaysHBIqAqMWGPOkiYTUBJYtPrG2AlIgKKEgdu 7GOFaJWT2NQ4lR2kXFhAXeLDuWCQMKdAoMTrJWuYIc45zihxpvklC8TR1hJLtrxnnsAoOAvJ RbOQXDQLyUULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq5WaW6KWmlG5iBIUuu4vSDsaf B5UOMQpwMCrx8HbsPR8sxJpYVlyZe4hRkoNJSZR3iu2FYCG+pPyUyozE4oz4otKc1OJDjBIc zEoivPdsgHK8KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWpRTBZXQ4OgWXTNloInNtz 9xijFEtefl6qkgTv6lCgSYJFqempFWmZOSUI9UwcnCDbeIC2+YPU8BYXJOYWZ6ZD5E8xKkqJ 81aFACUEQBIZpXlwvbDk84pRHOg3Yd5lIO08wMQF1/0KaDAT0OBXCedBBpckIqSkGhj7OhZ6 b1zbcm1fUVpji0NLz2GFxuZTrLM0mhMky9VuiNhIfBeM0jxSEt3te2DJUvXUEzk6Nl2emwuF 300TW/pth4pmQdrPn1Y3sy6l7H17SLDr7d0T2wPTTb4c8GJ+6BybudDs6XUtzed/ZN7tENx7 5dGkFR43JjNWbgy4uL2JaRnTYV9ptldKLMUZiYZazEXFiQD0Ke89GQMAAA== Subject: Re: [Caml-list] concurrent gc? > I should have noted that my main concern is with pauses, not with > overall speedup. In other words: in interactive apps, pauses are > eeeeeevil. > > > For technical reasons, offloading major collections in OCaml is easier > > than offloading minor collections, so the potential benefit is less. > > I am guessing you mean that major collections just don't happen that > often, at least if people write their code in a non-pathalogical > fashion? :) OCaml's runtime is designed around the assumption that access to the minor heap is fast and the minor heap is only emptied when the program is stopped. More generally, no object moves except when the program is stopped. Every minor collection moves objects, while most major collections do not. The runtime can even be told not to move objects during a major collection. So minor collections have to happen while the main program is stopped, or you have a large rather than a small change to the compiler-runtime interface. Full major collections are infrequent. The runtime is designed to do some amount of major collection work after each minor GC. For example, it might mark 10000 objects before restarting the program, even though there are a million objects in the heap. It is this "slice" of work that could be overlapped with execution of the main program. Before writing a concurrent garbage collector, try 1. Turn down the amount of work done at each major collection slice. 2. Reduce the size of the minor heap. See the Gc module and OCAMLRUNPARAM environment variable.