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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id C32E3800BE for ; Sat, 11 Feb 2017 15:10:55 +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.32; 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.32; 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.32; 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=3Ax8+ndRBmLtOCavWdOEYnUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP74oMbcNUDSrc9gkEXOFd2CrakV16yG4uu9CSRAuc/H6y9SNsQUFlcsso?= =?us-ascii?q?Y/oU8JOIa9E0r1LfrnPWQRPf9pcxtbxUy9KlVfA83kZlff8TWY5D8WHQjjZ0Iu?= =?us-ascii?q?frymUqabtcm81viz9pvPeE0IwWPlOfIhZCmx+C7RrMgNnYx6KpERVBTEuDMccO?= =?us-ascii?q?RMxHh0IkqT2Rb768i95rZo/iBdofsm8cMGWqL/KfcWV7tdWRInOGcxbdbckhvO?= =?us-ascii?q?QQK4zPcGGjEQkxFPBwHeqhb4U5v49CHzrMJ51TmbM8ywRrcxD2fxp5x3QQPl3X?= =?us-ascii?q?9UfwUy93va34kp1PpW?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAAAkGp9YhyDMOLleGwEBAQMBAQEJA?= =?us-ascii?q?QEBFQEBAQECAQEBAQgBAQEBhREHg1KcFhCXMoYiAoJ0B0MUAQEBAQEBAQEBAQE?= =?us-ascii?q?SAQEBCgsJCh0vgjMEARYBBIIXAQQBI1YFCwsEBzcCAiISAQUBHAYTCIlaCAQBo?= =?us-ascii?q?zU/jAKCJYtPAQEBBwEBAQEBI4s7hBuDP4JfBZU/hjOSFIt4hQ2RThQegRMCNoE?= =?us-ascii?q?hUVIXBYQ6gW50iGiBTgEBAQ?= X-IPAS-Result: =?us-ascii?q?A0CGAAAkGp9YhyDMOLleGwEBAQMBAQEJAQEBFQEBAQECAQE?= =?us-ascii?q?BAQgBAQEBhREHg1KcFhCXMoYiAoJ0B0MUAQEBAQEBAQEBAQESAQEBCgsJCh0vg?= =?us-ascii?q?jMEARYBBIIXAQQBI1YFCwsEBzcCAiISAQUBHAYTCIlaCAQBozU/jAKCJYtPAQE?= =?us-ascii?q?BBwEBAQEBI4s7hBuDP4JfBZU/hjOSFIt4hQ2RThQegRMCNoEhUVIXBYQ6gW50i?= =?us-ascii?q?GiBTgEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,146,1484002800"; d="scan'208,217";a="259897522" Received: from vrout10.yaziba.net ([185.56.204.32]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2017 15:10:55 +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 7A97451EE5 for ; Sat, 11 Feb 2017 15:10:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mtaout10.int.yaziba.net (Postfix) with ESMTP id 96205160112 for ; Sat, 11 Feb 2017 15:10:54 +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 VDBCweI2sX46 for ; Sat, 11 Feb 2017 15:10:54 +0100 (CET) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by mtaout10.int.yaziba.net (Postfix) with ESMTPSA id 4E9C71600AA for ; Sat, 11 Feb 2017 15:10:54 +0100 (CET) Received: by mail-qt0-f179.google.com with SMTP id w20so56608810qtb.1 for ; Sat, 11 Feb 2017 06:10:54 -0800 (PST) X-Gm-Message-State: AMke39lu/+yNkPfiwm/tDiSV70cB6rlrVo0BRm/8r7Q/g1HKo/gFvaqsNrDlVHgmDes2dNRdgF1ZE6+FGfxdUQ== X-Received: by 10.200.47.208 with SMTP id m16mr12343499qta.64.1486822253173; Sat, 11 Feb 2017 06:10:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.56.225 with HTTP; Sat, 11 Feb 2017 06:10:32 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= Date: Sat, 11 Feb 2017 15:10:32 +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=001a1143c65a3eb32d054841c8d2 X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrkeelgdeifecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepjghfhfffkffuvfgtsegrtderredttdejnecuhfhrohhmpefpihgtohhljohspgfqjhgvuggrpgeumohruceonhhitgholhgrshdrohhjvggurgdrsggrrheslhgvgihifhhirdgtohhmqeenucfkphepvddtledrkeehrddvudeirddujeelnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] How is the frametable handled when throwing exceptions? --001a1143c65a3eb32d054841c8d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 stack > 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: From > the C-API, it seems that all local roots are stored in the frametable via > 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 > --001a1143c65a3eb32d054841c8d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

Someone who knows m= ore will be able to get a better answer, but I don't think there is muc= h of an issue here:
when using the C API to register local roots (CAMLp= aram, 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 thos= e roots
are promptly forgotten (as they should be).
Cheers,
Nicolas


On Sat, Feb 11, 2017 at 3:0= 2 PM, Christoph H=C3=B6ger <christoph.hoeger@celeraone.com> wrote:
Dear all,

while studying camls native cod= e generation and garbage collection strategy, I came upon Connor Benner'= ;s bachelor thesis from 2012, where he implemented a llvm backend for ocaml= opt. One intriguing remark mentioned OCamls exception mechanism as basicall= y consisting a pointer to the stack frame of the last exception handler in = a special register (r14, when I recall correctly). Throwing an exception th= at becomes a mov/pop/ret operation. This however, seems to interfere with g= arbage collection: From the C-API, it seems that all local roots are stored= in the frametable via some special macros (e.g. CAMLParam, CAMLlocal).
When control just returns from a stack frame, how are the entrie= s removed from the frametable?

I would be glad, if someone co= uld answer this or point me to the relevant documentation (if any exists).<= br>
thanks,

Christoph

--001a1143c65a3eb32d054841c8d2--