Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Jon Harrop" <jon@ffconsultancy.com>
To: "'Stephen Dolan'" <stephen.dolan@cl.cam.ac.uk>,
	"'Gabriel Scherer'" <gabriel.scherer@gmail.com>
Cc: "'Pierre Chambart'" <pierre.chambart@laposte.net>,
	"'Goswin von Brederlow'" <goswin-v-b@web.de>,
	"'caml users'" <caml-list@inria.fr>
Subject: RE: [Caml-list] Why List.map does not be implemented tail-recursively?
Date: Mon, 1 Jun 2015 13:02:01 +0100	[thread overview]
Message-ID: <00fb01d09c62$c5da4ad0$518ee070$@ffconsultancy.com> (raw)
In-Reply-To: <CA+mHimPvTserK70uFMLinfQ97ttnts0xu3B1iw9jV4-sQZ36Wg@mail.gmail.com>

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

-----Original Message-----
From: stedolan@stedolan.net [mailto:stedolan@stedolan.net] On Behalf Of Stephen Dolan
Sent: 02 October 2014 11:10
To: Gabriel Scherer
Cc: Pierre Chambart; Goswin von Brederlow; caml users
Subject: Re: [Caml-list] Why List.map does not be implemented tail-recursively?

On Mon, Sep 29, 2014 at 10:00 PM, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
>> Please, don't do that hack ! The compiler assumes immutable data are 
>> not mutated and optimise knowing that.
>
> My understanding was that it is unsafe to Obj.magic an immutable data 
> structure into a mutable one (one mental model is that immutable data  
> might be allocated in read-only memory, although that's not what the 
> current implementation does), but that on the contrary it is safe to 
> Obj.magic a mutable data-structure into an immutable one. The 
> Obj.magic-using code for List.map, implemented in Extlib and inherited 
> by Batteries, is careful to use an unsafe cast in exactly the second 
> situation. This is a feature that other languages (eg. Mezzo) safely provide.

This trick is unsound in our implementation of multicore OCaml: the system assumes that immutable objects only point to older objects, and thus that a shared immutable object cannot point to a private immutable object. This can be hacked around (we have a similar hack for recursive immutable objects), but the point is that such tricks are fragile and depend on very implementation-specific behaviour.

Even in single-threaded OCaml, this trick is broken by quite reasonable compiler optimisations (although not ones that OCaml does today). For instance, if ocamlopt were to perform alias analysis and optimise based on the results, the first thing the alias analyser would do is conclude that references to immutable and mutable fields do not alias. This would allow it to swap the order of references to the immutable and mutable fields, and after inlining would mean that the cons cell is read before it is initialised.

Stephen

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


  reply	other threads:[~2015-06-01 12:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 19:31 Shuai Wang
2014-09-28 19:36 ` Gabriel Scherer
2014-09-28 19:45 ` Anthony Tavener
2014-09-29 12:08   ` Goswin von Brederlow
2014-09-29 14:02     ` Pierre Chambart
2014-09-29 15:44       ` Yaron Minsky
2014-09-29 21:00       ` Gabriel Scherer
2014-09-30  8:46         ` [Caml-list] Why List.map does not be implemented oleg
2014-09-30  9:07           ` Gabriel Scherer
2014-10-01 10:29             ` oleg
2014-10-01 12:00               ` Gerd Stolpmann
2014-10-29 10:11               ` Gabriel Scherer
2014-10-02 10:09         ` [Caml-list] Why List.map does not be implemented tail-recursively? Stephen Dolan
2015-06-01 12:02           ` Jon Harrop [this message]
2015-06-02 12:04             ` Stephen Dolan
2015-06-05 10:21               ` Goswin von Brederlow
2014-09-30  6:29       ` Goswin von Brederlow
  -- strict thread matches above, loose matches on Subject: below --
2014-09-28 19:28 Shuai Wang
2014-09-28 19:45 ` Malcolm Matalka
2014-09-28 20:26   ` Yaron Minsky
2014-09-29  2:31     ` Shuai Wang
2014-09-29  4:09       ` Anthony Tavener
2014-09-29  5:40         ` Martin Jambon
2014-09-29  9:13           ` Erkki Seppala
2014-09-29  9:15             ` Erkki Seppala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00fb01d09c62$c5da4ad0$518ee070$@ffconsultancy.com' \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    --cc=goswin-v-b@web.de \
    --cc=pierre.chambart@laposte.net \
    --cc=stephen.dolan@cl.cam.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox