Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Pierre Chambart <pierre.chambart@ocamlpro.com>
To: Michael Hicks <mwh@cs.umd.edu>, caml-list@inria.fr
Subject: Re: [Caml-list] Scanning objects outside the OCaml heap
Date: Tue, 07 Jul 2015 02:32:29 +0200	[thread overview]
Message-ID: <559B1E1D.8010501@ocamlpro.com> (raw)
In-Reply-To: <CAFb7wiWQe21EXdeGXjZk+iKKsXYDDY43YET3AQ8oY19xEWQaEw@mail.gmail.com>

On 07/07/2015 00:21, Michael Hicks wrote:
>
> I'm interested in implementing a custom memory management strategy
> that I can prove is safe in a language I will compile to OCaml. I'm
> thinking I'd like to allocate freeable memory outside the OCaml heap,
> but as OCaml values. Since these values can point to OCaml
> heap-resident data, they need to be scanned. But I don't want to have
> to explicitly register/deregister them as roots to the GC, or track
> all mutations to the values, if I can help it. Rather, having a single
> "persistent root" to my memory area, for purposes of scanning, would
> be ideal.
>
> Thanks in advance for any help,

There is an undocumented and unexported way to do something like that:
the caml_scan_roots_hook.
You can register a callback in this global variable that takes a
scanning action (another callback) to call
on every of your roots.

See https://github.com/ocaml/ocaml/blob/trunk/byterun/caml/roots.h#L34
for the definition
and https://github.com/ocaml/ocaml/blob/trunk/asmrun/roots.c#L270 as an
example of how the scanning
action should be called.

Since those roots are scanned only at the end of a gc major cycle, you
must handle mutation specificaly (like
mutations in the major heap). You will have to track them as you must
not have unnoticed pointers from outside
of the minor heap to the minor heap. You will have to addapt caml_modify
as it suppose that values not in the minor
are in the major heap. Since it is declared using a weak symbol, this
can be redefined without changing the
runtime. See http://caml.inria.fr/mantis/view.php?id=6084 .

Take care, as this is not exported in the official interface, this could
break at any version change of the runtime.
Have fun with your potential hard to debug segfaults ;)
-- 
Pierre

  reply	other threads:[~2015-07-07  0:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 22:21 Michael Hicks
2015-07-07  0:32 ` Pierre Chambart [this message]
2015-07-13  3:20 ` Oleg

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=559B1E1D.8010501@ocamlpro.com \
    --to=pierre.chambart@ocamlpro.com \
    --cc=caml-list@inria.fr \
    --cc=mwh@cs.umd.edu \
    /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