From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 827637EE33 for ; Sun, 12 Feb 2017 15:56:14 +0100 (CET) Authentication-Results: mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nicolas.ojeda.bar@lexifi.com) identity=pra; client-ip=185.56.204.32; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.ojeda.bar@lexifi.com"; x-sender="nicolas.ojeda.bar@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nicolas.ojeda.bar@lexifi.com) identity=mailfrom; client-ip=185.56.204.32; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.ojeda.bar@lexifi.com"; x-sender="nicolas.ojeda.bar@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@vrout10.yaziba.net) identity=helo; client-ip=185.56.204.32; receiver=mail3-smtp-sop.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=3A/R+DtBVQS3i3aY+cTbHPJX+1NCLV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbRWEt8tkgFKBZ4jH8fUM07OQ6PG8Hz1ZqsjR+Fk5M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6?= =?us-ascii?q?KfroEYDOkcu3y/qy+5rOaAlUmTaxe71/IRG5oAnLssQanIRuJ6cyxxDUvnZGZu?= =?us-ascii?q?NayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG8p6sLlsxnD?= =?us-ascii?q?VhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XCmp4ql3RBP0ji?= =?us-ascii?q?oMKiU0+3/LhMNukK1boQqhpx1hzI7SfIGVL+d1cqfEcd8HWWZNQsNdWipcCY2+?= =?us-ascii?q?coQPFfIMMuRWr4f9qVUArgawCxewC+700DBEmmX70Lcm3+g9EwzL2hErEdIUsH?= =?us-ascii?q?TTqdX4LL8cUeGpw6nPyTXEbehW1i/k5ojKbB8uvOuDUqptfM3U00kkCgTIjlOR?= =?us-ascii?q?qYP5ODOV0v4Cs3OB4+pnV+KglXMopBtrrje03MgskJLEhoYLxVHL9CV5zoc1Kc?= =?us-ascii?q?ekR058ZN6pCZ1dvDyUOYtxR8MtWWBouCAix70JuJ67YCgKyIk8yBLFd/OHdI2I?= =?us-ascii?q?7xT+X+iSOTd1nG9pdbG/ihqo8UWty/fwWteo3FtFtCZInMfAumgT2xDP7sWLUP?= =?us-ascii?q?hw80e71TqRyQzf9vtILV02mKbHLZMq36Q+mYAJsUvZGy/7gEX2g7GSdkUj4uWo?= =?us-ascii?q?9f7nYrL7pp+AKoN4lhvyM6Q0lc2+AOQ3KRIBU3Kd+euiyL3v5Uz5QLNUgf0qiq?= =?us-ascii?q?TVrZPXKMQBqqO5AgJZyJgv5wqwAju83tkUg2ELLFdfdxKGi4jpNUvOIPf9Dfqn?= =?us-ascii?q?hVSskStkx/fCPrL7GZXBNH/DkLX/crlg8UFQ0hE8wspF559PDrEOPv3yWk7/tN?= =?us-ascii?q?zZFBM2Lwu0w+P/BNVnyoweQX6PArOeMK7KrVCH/OcvI+2VaI8RuTb9MOQl6uX1?= =?us-ascii?q?jX45nF8dZbOm0YEWaHC+BPRmIl+WbWDigtcbCWsKuw0+Q/H0h1CaSj5TYmqyX7?= =?us-ascii?q?o75jEmFIL1RbvEE6utmr2awCCjHqp2+G9LEBjYGnfydp6YXO8MLiKVL8BsiBQP?= =?us-ascii?q?WLysUYYm0xzovwj/nelJNO3RrwsZvpXnXcNCwO/emRgF37BuR5Cb0mqKS2hv2G?= =?us-ascii?q?QKSjM/mqp2u2R5x0eC36k+iPtdQ48Ar8hVWxs3YMaPh9dxDMr/D0eYJo+E?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAABtdqBYhyDMOLleGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBhAiBCQeDUpwTEJcyKoQegVoCgnQHQxQBAQE?= =?us-ascii?q?BAQEBAQEBARIBAQEKCwkKHS+CMxsBghoBAQEDASNWBQsLCw0qAgIiEgEFARwGE?= =?us-ascii?q?4liCAQBCaI8P4wCgiWLQgEBAQEGAQEBAQEBHQWLO4Qbgz+CXwWVP4Yzhm+LJYF?= =?us-ascii?q?7iGeBFoUNkU4UHoETAjaBIVFSFwWDcEqBbnQBij4BAQE?= X-IPAS-Result: =?us-ascii?q?A0CrAABtdqBYhyDMOLleGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBhAiBCQeDUpwTEJcyKoQegVoCgnQHQxQBAQEBAQEBAQEBARIBA?= =?us-ascii?q?QEKCwkKHS+CMxsBghoBAQEDASNWBQsLCw0qAgIiEgEFARwGE4liCAQBCaI8P4w?= =?us-ascii?q?CgiWLQgEBAQEGAQEBAQEBHQWLO4Qbgz+CXwWVP4Yzhm+LJYF7iGeBFoUNkU4UH?= =?us-ascii?q?oETAjaBIVFSFwWDcEqBbnQBij4BAQE?= X-IronPort-AV: E=Sophos;i="5.35,153,1484002800"; d="scan'208,217";a="212935363" Received: from vrout10.yaziba.net ([185.56.204.32]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2017 15:56:13 +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 5FC4651E33 for ; Sun, 12 Feb 2017 15:56:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mtaout10.int.yaziba.net (Postfix) with ESMTP id 8754316024D for ; Sun, 12 Feb 2017 15:56:12 +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 9b4Om8Pw1R1p for ; Sun, 12 Feb 2017 15:56:12 +0100 (CET) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by mtaout10.int.yaziba.net (Postfix) with ESMTPSA id 3F5A0160243 for ; Sun, 12 Feb 2017 15:56:12 +0100 (CET) Received: by mail-qk0-f170.google.com with SMTP id s186so75853828qkb.1 for ; Sun, 12 Feb 2017 06:56:12 -0800 (PST) X-Gm-Message-State: AMke39lVxoez4DWGaPpcBypgAFsCcc0/NAa6by1TI4NefVPoDg3IYocpJYcCwHZQuVgtibYNNmHbKZgeKr49wA== X-Received: by 10.233.220.134 with SMTP id q128mr16424282qkf.220.1486911371111; Sun, 12 Feb 2017 06:56:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.56.225 with HTTP; Sun, 12 Feb 2017 06:55:50 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= Date: Sun, 12 Feb 2017 15:55:50 +0100 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christoph_H=C3=B6ger?= Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary=94eb2c044a6a1678210548568863 X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrledugdejgecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepjghfhfffkffuvfgtsegrtderredttdejnecuhfhrohhmpefpihgtohhljohspgfqjhgvuggrpgeumohruceonhhitgholhgrshdrohhjvggurgdrsggrrheslhgvgihifhhirdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedvtdelrdekhedrvddvtddrudejtdenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] How is the frametable handled when throwing exceptions? --94eb2c044a6a1678210548568863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christoph, No, the "frametable" is not a single static, global object (it would be hard to make this work with separate compilation, etc). Rather each function (both ML and C) is associated to a "frame descriptor" detailing where to find live values (for ML functions, the frame descriptor is associated to its function using the return address as a key). When the GC is triggered it traverses the stack (both ML and C) and collects the full list of GC roots. Of course there is also a list of "global" roots which *are* registered in a single, global table. For these roots indeed one must deregister them explicitly (see caml_{register,remove}_global_root and its "generational" friends). Some pointers: You can read the stack-walking code in https://github.com/ocaml/ocaml/blob/trunk/asmrun/roots.c#L438 When the GC is invoked when running ML code, this code depends on some global pointers which are set up in the asm glue, e.g. https://github.com/ocaml/ocaml/blob/trunk/asmrun/amd64.S Finally frame descriptors are emitted in the native-code backends, e.g.: https://github.com/ocaml/ocaml/blob/trunk/asmcomp/amd64/emit.mlp#L241 Hope this helps, Nicolas On Sun, Feb 12, 2017 at 2:25 PM, Christoph H=C3=B6ger < christoph.hoeger@celeraone.com> wrote: > Nicol=C3=A1s, > > that is my understanding, too. But what I am missing is the > _de_-registration of the roots. AFAIK, the frametable is a static, global > object and when the stack is cut down, it then contains stale pointers. So > either the frametable is useless (as a global object), because the GC > traverses the call stack or there is some kind of deregstration going on > somewhere. > > On Sat, Feb 11, 2017 at 3:10 PM, Nicol=C3=A1s Ojeda B=C3=A4r < > nicolas.ojeda.bar@lexifi.com> wrote: > >> Hi Christoph, >> >> Someone who knows more will be able to get a better answer, but I don't >> think there is much of an issue here: >> when using the C API to register local roots (CAMLparam, CAMLlocal, etc), >> these roots are in effect >> stored in the C stack. When raising an exception the stack is _cut down_ >> and all those roots >> are promptly forgotten (as they should be). >> >> Cheers, >> Nicolas >> >> >> On Sat, Feb 11, 2017 at 3:02 PM, Christoph H=C3=B6ger < >> christoph.hoeger@celeraone.com> wrote: >> >>> Dear all, >>> >>> while studying camls native code generation and garbage collection >>> strategy, I came upon Connor Benner's bachelor thesis from 2012, where = he >>> implemented a llvm backend for ocamlopt. One intriguing remark mentioned >>> OCamls exception mechanism as basically consisting a pointer to the sta= ck >>> frame of the last exception handler in a special register (r14, when I >>> recall correctly). Throwing an exception that becomes a mov/pop/ret >>> operation. This however, seems to interfere with garbage collection: Fr= om >>> the C-API, it seems that all local roots are stored in the frametable v= ia >>> some special macros (e.g. CAMLParam, CAMLlocal). >>> >>> When control just returns from a stack frame, how are the entries >>> removed from the frametable? >>> >>> I would be glad, if someone could answer this or point me to the >>> relevant documentation (if any exists). >>> >>> thanks, >>> >>> Christoph >>> >> >> > --94eb2c044a6a1678210548568863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

No, the "frametable&= quot; is not a single static, global object (it would be hard to make this = work with separate compilation, etc).
Rather each function (both = ML and C) is associated to a "frame descriptor" detailing where t= o find live values (for ML functions, the frame descriptor is associated to= its function using the return address as a key).=C2=A0 When the GC is trig= gered it traverses the stack (both ML and C) and collects the full list of = GC roots.=C2=A0 Of course there is also a list of "global" roots = which *are* registered in a single, global table.=C2=A0 For these roots ind= eed one must deregister them explicitly (see caml_{register,remove}_global_= root and its "generational" friends).

Some pointers:

You can read the stack-walking c= ode in

When the GC is invoked when running ML code, this code depends = on some global pointers which are set up in the asm
glue, e.g.


Finally= frame descriptors are emitted in the native-code backends, e.g.:

Hope this helps,
Nicolas


On Sun, Feb 12, 201= 7 at 2:25 PM, Christoph H=C3=B6ger <christoph.hoeger@celeraon= e.com> wrote:
Nicol=C3=A1s,

that is my understanding, too. But= what I am missing is the _de_-registration of the roots. AFAIK, the framet= able is a static, global object and when the stack is cut down, it then con= tains stale pointers. So either the frametable is useless (as a global obje= ct), because the GC traverses the call stack or there is some kind of dereg= stration going on somewhere.

On Sat,= Feb 11, 2017 at 3:10 PM, Nicol=C3=A1s Ojeda B=C3=A4r <= ;nicolas.= ojeda.bar@lexifi.com> wrote:
Hi Christoph,

Someone who knows= more will be able to get a better answer, but I don't think there is m= uch of an issue here:
when using the C API to register local roots (CAM= Lparam, CAMLlocal, etc), these roots are in effect
stored in the = C stack.=C2=A0 When raising an exception the stack is _cut down_ and all th= ose roots
are promptly forgotten (as they should be).
<= br>
Cheers,
Nicolas


On Sat, Feb 11, 201= 7 at 3:02 PM, Christoph H=C3=B6ger <christoph.hoeger@celeraon= e.com> wrote:
Dear all,

while studying cam= ls native code generation and garbage collection strategy, I came upon Conn= or Benner's bachelor thesis from 2012, where he implemented a llvm back= end for ocamlopt. One intriguing remark mentioned OCamls exception mechanis= m as basically consisting a pointer to the stack frame of the last exceptio= n handler in a special register (r14, when I recall correctly). Throwing an= exception that becomes a mov/pop/ret operation. This however, seems to int= erfere with garbage collection: From the C-API, it seems that all local roo= ts are stored in the frametable via some special macros (e.g. CAMLParam, CA= MLlocal).

When control just returns from a stack frame, how a= re the entries removed from the frametable?

I would be glad, = if someone could answer this or point me to the relevant documentation (if = any exists).

thanks,

Christoph



--94eb2c044a6a1678210548568863--