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 F19A07FA56 for ; Thu, 24 Jul 2014 21:35:05 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jfc@MIT.EDU) identity=pra; client-ip=18.9.25.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="jfc@MIT.EDU"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jfc@mit.edu designates 18.9.25.14 as permitted sender) identity=mailfrom; client-ip=18.9.25.14; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dmz-mailsec-scanner-3.mit.edu) identity=helo; client-ip=18.9.25.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="postmaster@dmz-mailsec-scanner-3.mit.edu"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsCABBf0VMSCRkOm2dsb2JhbABY1TYBgQ4WEAEBAQEBBgsLCRQphAQBBAE6PxBRPBsGiE0IA7h9hkkXGI8zB4RGAQSbNpgp X-IPAS-Result: ApsCABBf0VMSCRkOm2dsb2JhbABY1TYBgQ4WEAEBAQEBBgsLCRQphAQBBAE6PxBRPBsGiE0IA7h9hkkXGI8zB4RGAQSbNpgp X-IronPort-AV: E=Sophos;i="5.01,725,1400018400"; d="scan'208";a="86874749" Received: from dmz-mailsec-scanner-3.mit.edu ([18.9.25.14]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2014 21:35:05 +0200 X-AuditID: 1209190e-f79946d000007db1-9c-53d15fe7df94 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id AB.51.32177.7EF51D35; Thu, 24 Jul 2014 15:35:03 -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 s6OJZ2gA014102; Thu, 24 Jul 2014 15:35:02 -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 s6OJYu4g006184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Jul 2014 15:35:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21457.24542.885574.750018@gargle.gargle.HOWL> Date: Thu, 24 Jul 2014 15:34:54 -0400 From: "John F. Carr" To: Raoul Duke Cc: caml-list In-Reply-To: References: X-Mailer: VM 8.1.2 under 24.3.1 (amd64-portbld-freebsd10.0) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR4hRV1n0efzHYYNZcSYtPOzawWByf/ILJ gclj56y77B6TXhxiCWCK4rJJSc3JLEst0rdL4MqYdq6LpeA2X8WrlqWsDYx7uLsYOTkkBEwk /jzZygJhi0lcuLeerYuRi0NIYDaTxNMr1xlBEkICGxklFjwNgEicY5I4eXwnE0iCV0BQ4uTM J2DdzAJaEjf+vWSCsOUltr+dwwxRYyUxa9cHsEEsAqoS61Z1gtWwCShJbHp9A6xGREBR4sCN faxdjBxAvUoSD/74gYSFBQwlLu/4xA5icwoESmx7fJAFpERIIEBizWENiJutJZZsec88gVFw FpKDZiE5aBaSgxYwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdbLzSzRS00p3cQIDl5Jvh2M Xw8qHWIU4GBU4uHt2Hs+WIg1say4MvcQoyQHk5Ior2/UxWAhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIrwbg4ByvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWV0ODoFl0zZaCJzb c/cYoxRLXn5eqpIE7+o4oEmCRanpqRVpmTklCPVMHJwg23iAttmD1PAWFyTmFmemQ+RPMSpK ifO2giQEQBIZpXlwvbD084pRHOg3Yd6VIFU8wNQF1/0KaDAT0OBXCedBBpckIqSkGhgjJi/q 2yW8gU31iHLE60daztGLXr4/XWqrIagomt0scvHvst81dSaZp3gf9p85tNP097V9z3w2JEeq 3Ayq2rekfuXfFwdLnd88EhC5cGOdqIFb+o1TRke2ef94t/xZZ0D6bZbJi3dXhG++d4kxhc2f 94yz1dcCjfTsu+G9Wbc9Aq1kD/5oPfVBiaU4I9FQi7moOBEA2wS6AxoDAAA= Subject: [Caml-list] meta-gc (Re: concurrent gc?) > to kick the question up a meta-level: Does anybody have thoughts on > how to best orthogonalize actual memory allocation from where the > application says it wants it? I mean if I write a stupid loop that > makes a zillion particles in the middle of each frame render then yes > I'm an idiot, sure... but what things can be done to actually allow > such idiocy to squeak by? If you know in advance when you will need to run uninterrupted by garbage collection, set the minor heap size large before that period. If the minor heap size is X words and a collection has just completed, the next collection will occur when any of the following is true: 1. You have allocated X words of small objects, i.e. those that are 256 words or less exclusive of header. These are allocated from the minor heap. 2. You have allocated X words of large objects, i.e. those that are 257 words or more exclusive of header. These are allocated from the major heap and count as "old" even though they are new. 3. You have stored too many newly created small objects into objects that are either large or existed before the last GC, i.e. created too many old to young references. Set OCAMLRUNPARAM=v=8 and look for "ref_table threshold crossed" to see how often you hit this condition. It should be rare. Example: let a = Array.create 300 0 let b = Array.create 300 {x=0} let c = [|0|] let d = 0 let e = 0.0 and assume all of these values are live (used later). The first line allocates 301 words in the major heap. The second line allocates 301 words in the major heap, 2 words in the minor heap, and creates 300 major to minor (old to young) references. The third line allocates 2 words in the minor heap. The fourth line does not allocate memory from the heap. The fifth line may allocate 0, 2, or 3 words from the minor heap.