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 EBC90800BE for ; Fri, 6 Jan 2017 09:37:09 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=nicolas.ojeda.bar@lexifi.com; spf=None smtp.mailfrom=nicolas.ojeda.bar@lexifi.com; spf=None smtp.helo=postmaster@vrout10.yaziba.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nicolas.ojeda.bar@lexifi.com) identity=pra; client-ip=185.56.204.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.ojeda.bar@lexifi.com"; x-sender="nicolas.ojeda.bar@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nicolas.ojeda.bar@lexifi.com) identity=mailfrom; client-ip=185.56.204.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.ojeda.bar@lexifi.com"; x-sender="nicolas.ojeda.bar@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@vrout10.yaziba.net) identity=helo; client-ip=185.56.204.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.ojeda.bar@lexifi.com"; x-sender="postmaster@vrout10.yaziba.net"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3Are0cgxWehVg1XAFCAwi2zZ+InWjV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZhWCt8tkgFKBZ4jH8fUM07OQ6PG8HzZYqs/b7DhCKMUKDEBVz5?= =?us-ascii?q?1O3kQJO42sNw7SFLbSdSs0HcBPBhdO3kqQFgxrIvv4fEDYuXao7DQfSV3VPAtx?= =?us-ascii?q?IfnpSMaJ15zkn7P6x5qGSAVShSGhZqtyGzUoogjL/p0dgZFjMbo20huPonxFdO?= =?us-ascii?q?lM7X91YFiehRL94IG88cgw3T5XvqcH9sVHVSzhSIM6QLBROx6qKShh4szgsh3K?= =?us-ascii?q?Vk2I5HYQWyMcmwBgBwXV7R/7GJz2t32p5aJGxCCGMJiuHvgPUjO44vIzRQ=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQARVm9YhyLMOLleHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgwAOAQEBAQGCCgeNUHKTUw6VGIIJhiICgUZGFAEBAQEBAQEBAQE?= =?us-ascii?q?BEgEBAQgNCQodMIIzGIIeAQQBI0gOBQsLCzcCAiISAQUBHAYTCIhgCAQBo24/j?= =?us-ascii?q?AOCJYoZAQEBAQEFAQEBAQEBIosmhDKDHIJeBZUahXqRR5BbkQoUHoESAh+BdEo?= =?us-ascii?q?TBIQSEQuBYHKGKoI8AQEB?= X-IPAS-Result: =?us-ascii?q?A0ALAQARVm9YhyLMOLleHAEBBAEBCgEBFwEBBAEBCgEBgwA?= =?us-ascii?q?OAQEBAQGCCgeNUHKTUw6VGIIJhiICgUZGFAEBAQEBAQEBAQEBEgEBAQgNCQodM?= =?us-ascii?q?IIzGIIeAQQBI0gOBQsLCzcCAiISAQUBHAYTCIhgCAQBo24/jAOCJYoZAQEBAQE?= =?us-ascii?q?FAQEBAQEBIosmhDKDHIJeBZUahXqRR5BbkQoUHoESAh+BdEoTBIQSEQuBYHKGK?= =?us-ascii?q?oI8AQEB?= X-IronPort-AV: E=Sophos;i="5.33,323,1477954800"; d="scan'208,217";a="253125340" Received: from vrout10-bl.yaziba.net (HELO vrout10.yaziba.net) ([185.56.204.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2017 09:37:09 +0100 Received: from mtaout10.int.yaziba.net (mtaout10.int.yaziba.net [10.4.20.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vrout10.yaziba.net (mx10.yaziba.net) with ESMTPS id 72DDA5249A for ; Fri, 6 Jan 2017 09:37:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mtaout10.int.yaziba.net (Postfix) with ESMTP id 76C6C1603D4 for ; Fri, 6 Jan 2017 09:37:08 +0100 (CET) X-Virus-Scanned: amavisd-new at Received: from mtaout10.int.yaziba.net ([127.0.0.1]) by localhost (mtaout10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PmqXXWWknMlu for ; Fri, 6 Jan 2017 09:37:08 +0100 (CET) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by mtaout10.int.yaziba.net (Postfix) with ESMTPSA id 2E3411600DF for ; Fri, 6 Jan 2017 09:37:08 +0100 (CET) Received: by mail-qk0-f179.google.com with SMTP id u25so453105695qki.2 for ; Fri, 06 Jan 2017 00:37:08 -0800 (PST) X-Gm-Message-State: AIkVDXJfEvGWVcgA78cJd9hFLAiPKFM0C0QpDdywXoRwN821EoP7PrBQbmMCCgZNmPJsABp/T6Xs3ErWJ7Ar3A== X-Received: by 10.55.3.14 with SMTP id 14mr48409988qkd.86.1483691827133; Fri, 06 Jan 2017 00:37:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.32.226 with HTTP; Fri, 6 Jan 2017 00:36:46 -0800 (PST) In-Reply-To: <28b00f9b-d36c-b710-ade1-f250ad4f7c5e@tu-berlin.de> References: <28b00f9b-d36c-b710-ade1-f250ad4f7c5e@tu-berlin.de> From: =?UTF-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= Date: Fri, 6 Jan 2017 09:36:46 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christoph_H=C3=B6ger?= Cc: caml users Content-Type: multipart/alternative; boundary=001a114c951050079d054568ece2 X-DRWEB-SCAN: ok X-VRSPAM-SCORE: 0 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrvddtgdduvdelucetufdoteggodetrfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepjghfhfffkffuvfgtsegrtderredttdejnecuhfhrohhmpefpihgtohhljohspgfqjhgvuggrpgeumohruceonhhitgholhgrshdrohhjvggurgdrsggrrheslhgvgihifhhirdgtohhmqeenucfkphepvddtledrkeehrddvvddtrddujeelnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] Reason for static data in caml runtime --001a114c951050079d054568ece2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 > > --001a114c951050079d054568ece2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

While we wait for an expe= rt'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 standar= d C convention.

When calling C code (for example, = when the GC is triggered) we need to pass the content of
the regi= sters as used by OCaml (this includes things like the allocation pointer, e= xception
pointer, etc) to the C code so that they can be adjusted= as necessary.=C2=A0 Since these
registers need to be handled acc= ording 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 r= egisters when returning from the C code back into OCaml code.
As far as I know the global variables are only updated when pas= sing 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.=C2=A0 = I think I even remember
seeing some experiments in this direction= ...

(Corrections welcome!)

Thanks!

Cheers,
Nicolas

On Fri, Jan 6, 2017 a= t 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



<= /div>
--001a114c951050079d054568ece2--