From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id B6731800BF for ; Fri, 6 Jan 2017 12:54:20 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-qt0-f177.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.216.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.216.177 as permitted sender) identity=mailfrom; client-ip=209.85.216.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qt0-f177.google.com) identity=helo; client-ip=209.85.216.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-qt0-f177.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AuObWyxHGYYSuMT23WHsxEZ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ75psywAkXT6L1XgUPTWs2DsrQf2raQ6fmrAjRIoc7Y9itdINoUD15NoP?= =?us-ascii?q?5VtjJjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9?= =?us-ascii?q?fbytScaBx/iwgsaz8JrX6h5/oziwbbpFBpms5VHXt8IRhYJ5bKEzxxfA5HFBYc?= =?us-ascii?q?xSyHNpK1PVlBH5sJSe5plmpgtZsegg+soIaq76cr41V/QMAz0sKWE44IvwvhnO?= =?us-ascii?q?VwaVznQZW2QS1BFPBl6Wv1nBQp7tv36i5aJG0y6AMJiuQA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQD7hG9YhrHYVdFeGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgw4BAQEBAX6BDAeNUJRFiG+MN4IJKoV4AoF?= =?us-ascii?q?GBz8UAQEBAQEBAQEBAQESAQEBCAsLCh0wgjMYgh0BAQECAQEjHQEbDw4BAwELB?= =?us-ascii?q?gULDSoCAiIBEQEFARwGE4hUAQMQCA6jLj+MA4IDBQEcgwkFg14KGScNVIICAQE?= =?us-ascii?q?BAQEBAQECAQEBAQEBAQEYAgEFEoYzhGGEMkGCITqCXgWQEYUJhXuBeo9NkFuRC?= =?us-ascii?q?xQegRQfgUcSG0oTg14pDxELgX0gNQGGKYI8AQEB?= X-IPAS-Result: =?us-ascii?q?A0A6AQD7hG9YhrHYVdFeGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgw4BAQEBAX6BDAeNUJRFiG+MN4IJKoV4AoFGBz8UAQEBAQEBA?= =?us-ascii?q?QEBAQESAQEBCAsLCh0wgjMYgh0BAQECAQEjHQEbDw4BAwELBgULDSoCAiIBEQE?= =?us-ascii?q?FARwGE4hUAQMQCA6jLj+MA4IDBQEcgwkFg14KGScNVIICAQEBAQEBAQECAQEBA?= =?us-ascii?q?QEBAQEYAgEFEoYzhGGEMkGCITqCXgWQEYUJhXuBeo9NkFuRCxQegRQfgUcSG0o?= =?us-ascii?q?Tg14pDxELgX0gNQGGKYI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,324,1477954800"; d="scan'208,217";a="253162427" Received: from mail-qt0-f177.google.com ([209.85.216.177]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 06 Jan 2017 12:54:08 +0100 Received: by mail-qt0-f177.google.com with SMTP id k15so306272325qtg.3 for ; Fri, 06 Jan 2017 03:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqYLnwGD02xl031UwJXSlEtdNAyq2oMWbz5vNRg7IhI=; b=UVFVF7xtqYeuCNLxk36YMm+S1BNWFLUl5Rvvr2/+39q44pAPmIkUtBhvrz9la1XNb1 pLtJV9GRhrm+uEvyVFEioF1j5FSP43acQRhr3rnpcU3oIHGos4kuq1yS22vgwMPPGbCa QRbTjTzlZ/urJwUYmeVU7Z3h4/93MadT8f4VtmINyJPRgFanfki+V2UxRlJtkzcHOL3V Lc1Tfuwci7xVSbcIbMXZWHuPKo3VA3T9wgN/bM8b/VX5fCiTXiPiHWnA/bTHTGzd9JJ2 U6bIBv+MfUYxWIv4hlP0psGRcgjjpBvKDTmc2Z4iwSX5l0ljnKjtCN/M1JvEMz8ljMJk U0zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KqYLnwGD02xl031UwJXSlEtdNAyq2oMWbz5vNRg7IhI=; b=XsLMdSK8GiO4FEMvWI0NTQRaXuuUy0i8+RqhSjfqMbX4QxD0Z7swFon/m5lBU/CMDM YojcZA7+KQG0qLKW/fEtX4kVdFko0sxC/uNIMep6NE9bTa2m/3Cqg6C/Lnara/xA1G5t b+t1HMPmGWwcfkyDxMaUsMp65DjdCv+WkngaJsl9JHIVo/NJa74094/m8Oixk3GnF1BK GYqAKWsoJT04e1x347T7SiL46lWaJloQS4gNvggri8S8wHr7c1P/Zmi+Thn0IwhIxfSX dhhdWx07Y5vfubQW04JQN4R5bDSkC2onRkwWReSBEAE47RjX48RiP/JgJBBr0w+r3T1/ v4hA== X-Gm-Message-State: AIkVDXLyObZ6Ty5IF1ii0qrCqQSHixff66hwfD70+fZoJxXmnAd6M3TbbvDT43iTnN95WPmNixFJ+iWW9qHauQ== X-Received: by 10.237.34.167 with SMTP id p36mr69110814qtc.286.1483703647160; Fri, 06 Jan 2017 03:54:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.172.73 with HTTP; Fri, 6 Jan 2017 03:53:26 -0800 (PST) In-Reply-To: References: <28b00f9b-d36c-b710-ade1-f250ad4f7c5e@tu-berlin.de> From: Gabriel Scherer Date: Fri, 6 Jan 2017 06:53:26 -0500 Message-ID: To: =?UTF-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= Cc: =?UTF-8?Q?Christoph_H=C3=B6ger?= , caml users Content-Type: multipart/alternative; boundary=001a11397b22d75c9f05456bac94 Subject: Re: [Caml-list] Reason for static data in caml runtime --001a11397b22d75c9f05456bac94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A1s Ojeda B=C3=A4r < 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=C3=B6ger < > 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=C3=B6ger >> >> Technische Universit=C3=A4t Berlin >> Fakult=C3=A4t IV - Elektrotechnik und Informatik >> =C3=9Cbersetzerbau und Programmiersprachen >> >> Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin >> >> Tel.: +49 (30) 314-24890 >> E-Mail: christoph.hoeger@tu-berlin.de >> >> > > --001a11397b22d75c9f05456bac94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, Luca Saiu worked on it at OCamlPro in 2013, but I bel= ieve his funding ran out before the project could be completed. It is actua= lly not a trivial change to make, especially if you try to get a small over= head 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):
=C2=A0 http= s://www.ocamlpro.com/pub/multi-runtime.pdf

On Fri, Jan 6, 2017 at 3:36 AM, Nicol= =C3=A1s Ojeda B=C3=A4r <nicolas.ojeda.bar@lexifi.com> wrote:
Hi Christoph= ,

While we wait for an expert's answer, I allow myse= lf to add some observations
from my own investigations of the run= time 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, e= tc) to the C code so that they can be adjusted as necessary.=C2=A0 Since th= ese
registers need to be handled according the C calling conventi= on, we need to save their values somewhere.

The si= mplest 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 separ= ate heaps) running on the same process.=C2=A0 I think I even remember
=
seeing some experiments in this direction ...

(Corrections welcome!)

Thanks!

Cheers,
Nicolas

On Fr= i, Jan 6, 2017 at 9:10 AM, Christoph H=C3=B6ger <christoph.hoe= ger@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=C3=B6ger

Technische Universit=C3=A4t Berlin
Fakult=C3=A4t IV - Elektrotechnik und Informatik
=C3=9Cbersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: +49 (30) 314-24890
E-Mail: = christoph.hoeger@tu-berlin.de



<= /div>

--001a11397b22d75c9f05456bac94--