From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
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 9C0317EEF7
	for <caml-list@sympa.inria.fr>; Fri,  5 Jun 2015 12:21:35 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=pra; client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  goswin-v-b@web.de designates 212.227.17.11 as permitted
  sender) identity=mailfrom; client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; 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@mout.web.de) identity=helo;
  client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="postmaster@mout.web.de";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DZAQDld3FVnAsR49RbDoQ0xj4CgTY8EAEBAQEBAQERAQEBAQEGDQkJIS6EIwEBBDo/EAsYCSUPBSghE4gXARnVch+FUwEBAQcBAQEBHotDhQYHgxeBFgEEnkWHdwyPU4NdQG2CRwEBAQ
X-IPAS-Result: A0DZAQDld3FVnAsR49RbDoQ0xj4CgTY8EAEBAQEBAQERAQEBAQEGDQkJIS6EIwEBBDo/EAsYCSUPBSghE4gXARnVch+FUwEBAQcBAQEBHotDhQYHgxeBFgEEnkWHdwyPU4NdQG2CRwEBAQ
X-IronPort-AV: E=Sophos;i="5.13,558,1427752800"; 
   d="scan'208";a="163315382"
Received: from mout.web.de ([212.227.17.11])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:21:10 +0200
Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb102)
 with ESMTPSA (Nemesis) id 0LrJwm-1ZCwpC3o56-013AXX; Fri, 05 Jun 2015 12:21:06
 +0200
Received: from mrvn by frosties.localnet with local (Exim 4.84)
	(envelope-from <goswin-v-b@web.de>)
	id 1Z0okL-00051l-Co; Fri, 05 Jun 2015 12:21:05 +0200
Date: Fri, 5 Jun 2015 12:21:05 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Stephen Dolan <stephen.dolan@cl.cam.ac.uk>
Cc: jon@ffconsultancy.com, Gabriel Scherer <gabriel.scherer@gmail.com>,
	Pierre Chambart <pierre.chambart@laposte.net>,
	caml users <caml-list@inria.fr>
Message-ID: <20150605102105.GA19196@frosties>
References: <CAEQMQo=bZnk2+GRD1RpW_W-2GVrugVPgMCguwAYSYj7dqY3A_g@mail.gmail.com>
 <CAN=ouMSbJNEWeJ=1XG1nqRSS=c3WMFvHMQF+jDOh9rDyz62dJQ@mail.gmail.com>
 <20140929120817.GB20628@frosties>
 <54296663.8080902@laposte.net>
 <CAPFanBHFO_t3N+f2hTZ+hytEj=8fhBAik-PYFcrcn2VayJ+dvw@mail.gmail.com>
 <CA+mHimPvTserK70uFMLinfQ97ttnts0xu3B1iw9jV4-sQZ36Wg@mail.gmail.com>
 <00fb01d09c62$c5da4ad0$518ee070$@ffconsultancy.com>
 <CA+mHimMfPCrF-5ai3uhKuee=m+LVjBc1e7WJ14WireiLWWmiHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+mHimMfPCrF-5ai3uhKuee=m+LVjBc1e7WJ14WireiLWWmiHQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Provags-ID:  V03:K0:qCOacVyV40iUV4IPR1YtI+I7z3kTSnCMoe+u+IgiajiK2KnLrzL
 w11AU74jOMyHgdpu2TSL/ffzsdJwEBfOautNmVU7eFIk9CGzhNW96Hzq+JTzEAp6EcMPAWO
 pJiEfy/Q5Umeqdd03RerCDcMch4UrOxc51OPsARlxuaPmPSN8Oq2xiFdsu5jXD7wFJYIGAf
 oITWeiZEIPAa3Z98FnEdA==
X-UI-Out-Filterresults: notjunk:1;
Subject: Re: [Caml-list] Why List.map does not be implemented
 tail-recursively?

On Tue, Jun 02, 2015 at 01:04:46PM +0100, Stephen Dolan wrote:
> On Mon, Jun 1, 2015 at 1:02 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > What happens when the first allocation in the creation of a cyclic immutable structure incurs a minor collection?
> >
> > let rec xs = 0::ys and ys = 1::xs
> 
> Such allocations are handled specially. Essentially, it boils down to
> having a write barrier on the final mutation that ties the knot on the
> cyclic data structure. This isn't multicore-specific: see
> caml_alloc_dummy and caml_update_dummy in byterun/alloc.c for the gory
> details.
> 
> In multicore, this mutation needs to promote (copy to the shared heap)
> the cyclic data structure if the head node has already been collected.
> 
> Stephen

I believe ocaml already optimizes this into a single allocation for
both objects. So there can't be a GC run between them. And even if
there is, both xs and ys are alive in the local stackframe and can not
be collected just yet.

MfG
	Goswin