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 4AE397EE33 for ; Sun, 12 Feb 2017 14:25:13 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=christoph.hoeger@celeraone.com; spf=Pass smtp.mailfrom=christoph.hoeger@celeraone.com; spf=None smtp.helo=postmaster@mail-it0-f49.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@celeraone.com) identity=pra; client-ip=209.85.214.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="christoph.hoeger@celeraone.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of christoph.hoeger@celeraone.com designates 209.85.214.49 as permitted sender) identity=mailfrom; client-ip=209.85.214.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="christoph.hoeger@celeraone.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-it0-f49.google.com) identity=helo; client-ip=209.85.214.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@celeraone.com"; x-sender="postmaster@mail-it0-f49.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AzLX/kxKtKzPEw/WE49mcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgUKfvxwZ3uMQTl6Ol3ixeRBMOAuq4C2rOd7vioGTRZp83e4DZaKN0EfiRGoP?= =?us-ascii?q?tVtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBke3blIt?= =?us-ascii?q?dazdU7TfhMWv1u2054abI0AR3GL8MvtOK0CQrA7WskANtqxgJ6o4/TFFuDMcfe?= =?us-ascii?q?VdwmdhPhSUnRvw74G69YRL9ylAuvwgscVHVPOpUb4/SOlzDC4nKHwy/M3clYfM?= =?us-ascii?q?QBHHsnAcSGQNjh1QA07F6xz1U43ZuSb+u/B03y+Xe8bxSOZnCnyZ8653RUqw22?= =?us-ascii?q?88PDkj/TSS05QogQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQBaYaBYgDHWVdFeGwEBAQMBAQEJA?= =?us-ascii?q?QEBFQEBAQECAQEBAQgBAQEBhREHg1KcFJAKhSyCDIYiAoJ0B0EWAQEBAQEBAQE?= =?us-ascii?q?BAQESAQEJDQkKGzGCMwQBFgEEghYBAQEDASMdAQE3AQQLCwQHDSoCAiISAQUBH?= =?us-ascii?q?AYTiWIIokc/ixpogiWDCAEBBYgzAQEBAQYBAQEBAQEaCBKLKYQbgz+CX5VEhjO?= =?us-ascii?q?SFIt4hQ2RThQegRUmCIEpUVIXBYQagg4/NQGIGYFOAQEB?= X-IPAS-Result: =?us-ascii?q?A0AAAQBaYaBYgDHWVdFeGwEBAQMBAQEJAQEBFQEBAQECAQE?= =?us-ascii?q?BAQgBAQEBhREHg1KcFJAKhSyCDIYiAoJ0B0EWAQEBAQEBAQEBAQESAQEJDQkKG?= =?us-ascii?q?zGCMwQBFgEEghYBAQEDASMdAQE3AQQLCwQHDSoCAiISAQUBHAYTiWIIokc/ixp?= =?us-ascii?q?ogiWDCAEBBYgzAQEBAQYBAQEBAQEaCBKLKYQbgz+CX5VEhjOSFIt4hQ2RThQeg?= =?us-ascii?q?RUmCIEpUVIXBYQagg4/NQGIGYFOAQEB?= X-IronPort-AV: E=Sophos;i="5.35,152,1484002800"; d="scan'208,217";a="259956748" Received: from mail-it0-f49.google.com ([209.85.214.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 12 Feb 2017 14:25:12 +0100 Received: by mail-it0-f49.google.com with SMTP id x75so16416340itb.0 for ; Sun, 12 Feb 2017 05:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=celeraone-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vd3F2Z91nHL249edKGQKRbGy+YriuB/+7GDBkSPBVzU=; b=aftXMQl+OR1P9Ze3lRfAbyaCr/WsmHOUj47SVDSZFCZrXhLFPbTyRcFewgy9G4XadO TWabNFDOA6d1ANd1wG1fmQX77gKz3BXDWTRTu+PPRfj0OI10WUNNWteW0w8s9djQEjhJ +dVvovLFj4g5EkLeKf+Cb32vTdEHw429jU5OSnM8S0fOFzuQOq0AF/k8l2o6SXxa99wo hSVbEHRlbE2vfLhfPZO9TA6LpOuOJa8CLSjCHiQRXAcRW/xdXbQKtc0jVZr721YoAPnG JNAGRcJaQ++ltm+fvnjfVKPd0b8qNKObknemtoi/+YP4+g2/jQIJSFwmxE8Mri06Lg47 OBWw== 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=Vd3F2Z91nHL249edKGQKRbGy+YriuB/+7GDBkSPBVzU=; b=ohra+xUbsDCg6MQPHH/dAs1fBWkNXNPbgkkeWOLEttdV+1cYM7JaSVlAQVAhbeNFVQ HU2/OSNFyQwywFlTzq6WTDzNr60niNCer/ChotXSrt22yLmMWqKvni+SI7h8o3Hodvdv Z4RY5InWpM1QgibCklnl+Q1bemt/SwTWu5p6oDAKfgWpMZgcE+3rdYEBhKO+v4/D9xxp z8Gz3YpcUonneW/ZnpX6lXL1uRE1ZB6cjHBjLPOxPJk4p77ZAkm6uN8WvTEZZDuX93+p ZcudPE0W+w10+N9suidMenPJdzDjiLzzSuqFQ562z3NM90QXpJInmPTt0r57XvJGKLNB Lwwg== X-Gm-Message-State: AMke39l3dcNlaxqLcnGDqb6eQGR2NGiJfHIb5v6lqYeswDgYZ9I+NO7MGF+o8XvcJ9XoJ1UtCtdEWQVQWHJO3ghW X-Received: by 10.36.123.145 with SMTP id q139mr17441333itc.62.1486905910742; Sun, 12 Feb 2017 05:25:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.48.211 with HTTP; Sun, 12 Feb 2017 05:25:10 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Christoph_H=C3=B6ger?= Date: Sun, 12 Feb 2017 14:25:10 +0100 Message-ID: To: =?UTF-8?Q?Nicol=C3=A1s_Ojeda_B=C3=A4r?= Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary=001a1146f030a00210054855428d Subject: Re: [Caml-list] How is the frametable handled when throwing exceptions? --001a1146f030a00210054855428d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 >> > > --001a1146f030a00210054855428d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nicol=C3=A1s,

that is my understand= ing, too. But what I am missing is the _de_-registration of the roots. AFAI= K, 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, N= icol=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:
w= hen using the C API to register local roots (CAMLparam, CAMLlocal, etc), th= ese roots are in effect
stored in the C stack.=C2=A0 When raising= an exception the stack is _cut down_ and all those roots
are pro= mptly forgotten (as they should be).

Cheers,
=
Nicolas


On Sat, Feb 1= 1, 2017 at 3:02 PM, Christoph H=C3=B6ger <christoph.hoeger@ce= leraone.com> wrote:
Dear all,

while studyi= ng camls native code generation and garbage collection strategy, I came upo= n Connor Benner's bachelor thesis from 2012, where he implemented a llv= m backend for ocamlopt. One intriguing remark mentioned OCamls exception me= chanism as basically consisting a pointer to the stack frame of the last ex= ception handler in a special register (r14, when I recall correctly). Throw= ing 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 loc= al roots are stored in the frametable via some special macros (e.g. CAMLPar= am, 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 documentatio= n (if any exists).

thanks,

Christoph


--001a1146f030a00210054855428d--