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

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

[Christoph Höger]

[-- Attachment #1.1: Type: text/plain, Size: 1142 bytes --]

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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Nicolás Ojeda Bär]

[-- 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 --]

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

[Gabriel Scherer]

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

Yes, Luca Saiu worked on it at OCamlPro in 2013, but I believe his funding
ran out before the project could be completed. It is actually not a trivial
change to make, especially if you try to get a small overhead compared to
the currently global version (I don't remember whether Luca gave more
precise number, but the slides below say "no more than 5%-10% overhead",
which is not an innocuous change):
  https://www.ocamlpro.com/pub/multi-runtime.pdf

On Fri, Jan 6, 2017 at 3:36 AM, Nicolás Ojeda Bär <
nicolas.ojeda.bar@lexifi.com> wrote:

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