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 7BBAB7FA4D for ; Tue, 29 Jul 2014 13:49:05 +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.9.25.15; 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.9.25.15 as permitted sender) identity=mailfrom; client-ip=18.9.25.15; 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-4.mit.edu) identity=helo; client-ip=18.9.25.15; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jfc@mit.edu"; x-sender="postmaster@dmz-mailsec-scanner-4.mit.edu"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkCANKI11MSCRkPh2dsb2JhbABZ128BgQ4WEAEBAQoLCQcWKYQEAQQBOj8QCw44PBsGiE0IA7hPhjwXGI80B4RKAQSbTJgz X-IPAS-Result: AqkCANKI11MSCRkPh2dsb2JhbABZ128BgQ4WEAEBAQoLCQcWKYQEAQQBOj8QCw44PBsGiE0IA7hPhjwXGI80B4RKAQSbTJgz X-IronPort-AV: E=Sophos;i="5.01,756,1400018400"; d="scan'208";a="73178749" Received: from dmz-mailsec-scanner-4.mit.edu ([18.9.25.15]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2014 13:49:04 +0200 X-AuditID: 1209190f-f79f86d0000061c8-b2-53d78a2e1e26 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4B.83.25032.E2A87D35; Tue, 29 Jul 2014 07:49:02 -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 s6TBn1Tb031571; Tue, 29 Jul 2014 07:49: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 s6TBmt20023932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 07:49:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21463.35366.495887.430955@gargle.gargle.HOWL> Date: Tue, 29 Jul 2014 07:48:54 -0400 From: "John F. Carr" To: Yaron Minsky Cc: In-Reply-To: References: <1404501528.4384.4.camel@e130> <20140728111452.GA26816@frosties> X-Mailer: VM 8.1.2 under 24.3.1 (amd64-portbld-freebsd10.0) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrKvXdT3YoPeGssWnHRtYLJ52LmJx YPKY9OIQi8edL0/ZA5iiuGxSUnMyy1KL9O0SuDIaLj5hL/jBWjF1xkSmBsb7LF2MnBwSAiYS Cy6/gLLFJC7cW8/WxcjFISQwm0niytnJ7BDORkaJg2vfQjnnmCQOL28Ba+EVEJQ4OfMJmM0s oCVx499LJghbXmL72znMEDVWEm9ufgarYRFQlWiZ9R7MZhNQktj0+gZYjYiApkTD/dusEL0S Eje2PmYHsYWBZs5/cYmxi5GDg1MgUGLVGXmIGxYzSTzc8oEZ4mxriSVb3jNPYBScheSkWUhO moXkpAWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzGCQ1iSfwfjt4NKhxgF OBiVeHg5FlwLFmJNLCuuzD3EKMnBpCTKO6H2erAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV63 DqAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVpeDQ2DZtI0WAuf23D3GKMWS l5+XqiTBq9oJNEmwKDU9tSItM6cEoZ6JgxNkGw/QtjqQGt7igsTc4sx0iPwpoHmL9r/sZhIC GyQlzusIUiQAUpRRmgc3B5acXjGKA/0pzOsBUsUDTGxwk14BLWECWsLqArakJBEhJdXAqBP8 Ys5Jzs2JlXevCvuy8kYmcTu+8puyhNnxzkGdWclMJdMfTy1ePlPvytaDS7ITlW9u7H/gPlXu kvSNTczRsllzaydw59aXWUzUyOlSk+lnaphx7vwVhzR5vZuRnO6HJvzr6JDJqzLYoercau2z c9FsrgOntnsW3JB/OoGfX2vHW8VG1XXnlFiKMxINtZiLihMB7UhEJCkDAAA= Subject: Re: [Caml-list] Immutable strings > This isn't my idea, but it seems worth repeating: perhaps it would > make sense to have an unmovable byte-array type that had the same > memory representation as Bytes.t, with the extra guarantee that the > collector wouldn't move it. I don't think this can be implemented without a significant runtime change. If your program is special enough to need pinned strings, try turning off compaction with Gc.set. The collector will never move objects larger than 256 words. It is easy to allocate a string from outside the heap, so the collector can not move it, but then you have to do manual memory management. Manual memory management means explicit free or a finalizer on an object you know will outlive any reference to the string.