Re: [Caml-list] How is the frametable handled when throwing exceptions?

["Christoph Höger" <christoph.hoeger@celeraone.com>]

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

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: 2715 bytes --]