caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Nicolás Ojeda Bär" <nicolas.ojeda.bar@lexifi.com>
To: "Christoph Höger" <christoph.hoeger@celeraone.com>
Cc: OCaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] How is the frametable handled when throwing exceptions?
Date: Sun, 12 Feb 2017 15:55:50 +0100	[thread overview]
Message-ID: <CADK7aFO42v=Ht8QQ63-CSJg+dfCzh4n_=6C_nTi00LOwtQHCZg@mail.gmail.com> (raw)
In-Reply-To: <CAOazmvsLA8-A8c_wHG_vE1BzEqMmPLDnWr5F4XRrqA-aa1zgpA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]

Hi Christoph,

No, the "frametable" is not a single static, global object (it would be
hard to make this work with separate compilation, etc).
Rather each function (both ML and C) is associated to a "frame descriptor"
detailing where to find live values (for ML functions, the frame descriptor
is associated to its function using the return address as a key).  When the
GC is triggered it traverses the stack (both ML and C) and collects the
full list of GC roots.  Of course there is also a list of "global" roots
which *are* registered in a single, global table.  For these roots indeed
one must deregister them explicitly (see caml_{register,remove}_global_root
and its "generational" friends).

Some pointers:

You can read the stack-walking code in

  https://github.com/ocaml/ocaml/blob/trunk/asmrun/roots.c#L438

When the GC is invoked when running ML code, this code depends on some
global pointers which are set up in the asm
glue, e.g.

  https://github.com/ocaml/ocaml/blob/trunk/asmrun/amd64.S

Finally frame descriptors are emitted in the native-code backends, e.g.:

  https://github.com/ocaml/ocaml/blob/trunk/asmcomp/amd64/emit.mlp#L241

Hope this helps,
Nicolas


On Sun, Feb 12, 2017 at 2:25 PM, Christoph Höger <
christoph.hoeger@celeraone.com> wrote:

> Nicolás,
>
> that is my understanding, too. But what I am missing is the
> _de_-registration of the roots. AFAIK, the frametable is a static, global
> object and when the stack is cut down, it then contains stale pointers. So
> either the frametable is useless (as a global object), because the GC
> traverses the call stack or there is some kind of deregstration going on
> somewhere.
>
> On Sat, Feb 11, 2017 at 3:10 PM, Nicolás Ojeda Bär <
> nicolas.ojeda.bar@lexifi.com> wrote:
>
>> Hi Christoph,
>>
>> Someone who knows more will be able to get a better answer, but I don't
>> think there is much of an issue here:
>> when using the C API to register local roots (CAMLparam, CAMLlocal, etc),
>> these roots are in effect
>> stored in the C stack.  When raising an exception the stack is _cut down_
>> and all those roots
>> are promptly forgotten (as they should be).
>>
>> Cheers,
>> Nicolas
>>
>>
>> On Sat, Feb 11, 2017 at 3:02 PM, Christoph Höger <
>> christoph.hoeger@celeraone.com> wrote:
>>
>>> Dear all,
>>>
>>> while studying camls native code generation and garbage collection
>>> strategy, I came upon Connor Benner's bachelor thesis from 2012, where he
>>> implemented a llvm backend for ocamlopt. One intriguing remark mentioned
>>> OCamls exception mechanism as basically consisting a pointer to the stack
>>> frame of the last exception handler in a special register (r14, when I
>>> recall correctly). Throwing an exception that becomes a mov/pop/ret
>>> operation. This however, seems to interfere with garbage collection: From
>>> the C-API, it seems that all local roots are stored in the frametable via
>>> some special macros (e.g. CAMLParam, CAMLlocal).
>>>
>>> When control just returns from a stack frame, how are the entries
>>> removed from the frametable?
>>>
>>> I would be glad, if someone could answer this or point me to the
>>> relevant documentation (if any exists).
>>>
>>> thanks,
>>>
>>> Christoph
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5005 bytes --]

  reply	other threads:[~2017-02-12 14:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-11 14:02 Christoph Höger
2017-02-11 14:10 ` Nicolás Ojeda Bär
2017-02-12 13:25   ` Christoph Höger
2017-02-12 14:55     ` Nicolás Ojeda Bär [this message]
2017-02-13 15:13 ` Stephen Dolan

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='CADK7aFO42v=Ht8QQ63-CSJg+dfCzh4n_=6C_nTi00LOwtQHCZg@mail.gmail.com' \
    --to=nicolas.ojeda.bar@lexifi.com \
    --cc=caml-list@inria.fr \
    --cc=christoph.hoeger@celeraone.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).