Re: [Caml-list] Reason for static data in caml runtime

["Nicolás Ojeda Bär" <nicolas.ojeda.bar@lexifi.com>]

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

Hi Christoph,

While we wait for an expert's answer, I allow myself to add some
observations
from my own investigations of the runtime system (hopefully correct):

* OCaml uses very different calling convention than the standard C
convention.

When calling C code (for example, when the GC is triggered) we need to pass
the content of
the registers as used by OCaml (this includes things like the allocation
pointer, exception
pointer, etc) to the C code so that they can be adjusted as necessary.
Since these
registers need to be handled according the C calling convention, we need to
save their values somewhere.

The simplest way to do this is to pass them to the C code using global
variables and restore those
globals into the registers when returning from the C code back into OCaml
code.

As far as I know the global variables are only updated when passing the
OCaml-C boundary.

* Having said that one could bundle all the globals in one record so as to
allow multiple
OCaml processes (with separate heaps) running on the same process.  I think
I even remember
seeing some experiments in this direction ...

(Corrections welcome!)

Thanks!

Cheers,
Nicolas

On Fri, Jan 6, 2017 at 9:10 AM, Christoph Höger <
christoph.hoeger@tu-berlin.de> wrote:

> Dear all,
>
> after investigating the interaction of native code and the runtime
> environment (in particular the GC), I am puzzled about the static
> storage of some data (e.g. the young_pointer, global roots etc):
>
> * if I am not mistaken, each function obtains the young pointer in a
> register (%rax on x86)
>
> * the same value is stored globally in a variable allocated by the
> executable
>
> * several other variables are allocated that way
>
> I wonder why this is necessary. If the generated code uses one register
> anyway, why not put a pointer to the necessary global data structures in
> there as well? (say, in the first element of the minor heap).
>
> I am probably missing something here, but at first glance this strategy
> prevents concurrent ocaml execution in one process and at the same time
> it seems to be fixable, right?
>
> thanks for any comments,
>
> Christoph
> --
> Christoph Höger
>
> Technische Universität Berlin
> Fakultät IV - Elektrotechnik und Informatik
> Übersetzerbau und Programmiersprachen
>
> Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin
>
> Tel.: +49 (30) 314-24890
> E-Mail: christoph.hoeger@tu-berlin.de
>
>

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