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