caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Lukasz Stafiniak <lukstafi@gmail.com>
Cc: Caml <caml-list@inria.fr>
Subject: Re: [Caml-list] OCaml and Boehm
Date: Mon, 13 Apr 2009 19:36:53 +0200	[thread overview]
Message-ID: <49E37835.5090306@inria.fr> (raw)
In-Reply-To: <4a708d20904101313s49ef3b75m45202b6bda800b77@mail.gmail.com>

> Is the OCaml runtime Boehm-safe? That is, can it be run with Boehm
> turned on and traversing OCaml's heap? (So that the OCaml heap can
> provide roots to Boehm.)

I conjecture the answer is "yes", although it's hard to tell for sure
without a precise specification of what is/is not OK with the
Boehm-Demers-Weiser collector.

>From the standpoint of this collector, OCaml's heap is just a set of
large-ish blocks allocated with malloc()  (*) and containing a zillion
pointers within those blocks.  OCaml doesn't play any dirty tricks
with pointers: no xoring of two pointers, no pointers represented as
offsets from a base, no pointers one below or one above a malloc-ed
block.  Most pointers are word-aligned but we sometimes play tricks
with the low 2 bits.

Of course, almost all Caml pointers point inside those malloc-ed
blocks, not to the beginning, but I'm confident that the B-D-W collector
can handle this, otherwise it would fail on pretty much any existing C
code.

This said, I agree with Basile that what you're trying to achieve
(coexistence between several GCs) is risky, and that a design based on
message passing and separated memory spaces would be more robust, if
feasible.

- Xavier Leroy


(*) In 3.10 and earlier releases, OCaml sometimes used mmap() instead
of malloc() to obtain these blocks.  Starting from 3.11, malloc() is
the only interface OCaml uses to obtain memory from the OS.


  parent reply	other threads:[~2009-04-13 17:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10 20:13 Lukasz Stafiniak
2009-04-11  9:46 ` [Caml-list] " Basile STARYNKEVITCH
2009-04-11 10:42   ` Jon Harrop
     [not found]   ` <4a708d20904110511o7d390807r3d29400cf96d6f35@mail.gmail.com>
     [not found]     ` <49E09C2D.4080906@starynkevitch.net>
2009-04-11 14:11       ` Lukasz Stafiniak
2009-04-11 14:27         ` Jon Harrop
2009-04-11 14:40           ` Lukasz Stafiniak
2009-04-11 20:40             ` Jon Harrop
2009-04-11 15:03         ` Basile STARYNKEVITCH
2009-04-11 20:41           ` Jon Harrop
2009-04-13  9:42           ` Christoph Bauer
2009-04-13 13:15             ` Lukasz Stafiniak
2009-04-14  5:25               ` Goswin von Brederlow
2009-04-12  3:34   ` Goswin von Brederlow
2009-04-12 12:09     ` Lukasz Stafiniak
2009-04-13 17:36 ` Xavier Leroy [this message]
2009-04-11 19:17 Ed Keith
2009-04-11 20:36 ` Jon Harrop
2009-04-12  3:25   ` Goswin von Brederlow

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=49E37835.5090306@inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=lukstafi@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).