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 c5ff346549e7 (Postfix) with ESMTPS id E99315D5 for ; Sat, 5 May 2018 03:25:03 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.49,364,1520895600"; d="scan'208,217";a="325843654" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 05 May 2018 05:24:56 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id BB3698244F; Sat, 5 May 2018 05:24:56 +0200 (CEST) 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 4367B8240C for ; Sat, 5 May 2018 05:24:49 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=murthy.chet@gmail.com; spf=Pass smtp.mailfrom=murthy.chet@gmail.com; spf=None smtp.helo=postmaster@mail-ua0-f170.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AMy3/Rx9ttJDa4P9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1u8cTK2v8tzYMVDF4r011RmVBd6ds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+55Pebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbY6SKfR+Y7jdfcsESmVdQsZfWStBAoam?= =?us-ascii?q?YIsOCeoKIOJUoob5qlcLqxa1GAuiC/71yjJQhHD206003eoiHw/bwgIvA8kDv2?= =?us-ascii?q?7IoNjvLqoeTfy5wavOwD7eb/1WwzD96I3Qfx0/ofGDQ65wetfWx0kyDQPFklWQ?= =?us-ascii?q?qIz4ND6S0+QNrnKb7/ZgVeOvkWIotwFxrSazxso3hYnJg5gaylHA9Slj3Ik1It?= =?us-ascii?q?i4RVd9bNW5HpVQsCSaOJF3QsMkW2xouSA6yqcHuZGhZiQKxo4nywbfavOdc4iI?= =?us-ascii?q?5RXjWPyNLjd/gXJofq+0iRWq8UW41OHwSs253ExJoydFiNXAqG0B2h7J5sSaSP?= =?us-ascii?q?Zx4kGs0iuV2Q/J8OFLO0U0mLLbK5E/xr4wkYIesUHZES/3nEX6lbKWeV849uSx?= =?us-ascii?q?5eTrf7frqoOGO497jQH+NasumsihDugiLgcOWG2b9fy91L3l40L5XK1HguMqnq?= =?us-ascii?q?TdqpzXJsQWqrSnDwNI0Isv8QuzAjW63NgAmHkINlNFeBaJj4jzPFHOJej1DfKi?= =?us-ascii?q?g1S2jDdrx/DHMqf9DZXNMHfDjKzsfbl460FGyQozycpT6I5TCrEEOP7zQFP+tM?= =?us-ascii?q?TEDh8lNAy52/roB8941oMaQG6PBq6ZMLjOsVKT/eIuI+yMZJcPtzrnKvgl4eTu?= =?us-ascii?q?jX4jllMHc6mpx8hfVHftMO5rL0iDYHGkutobC2YNokJqQvTnkkeDViJ7aHO7Xq?= =?us-ascii?q?Z67TY+XtGIF4DGE6utjaDJ+TqhAp1HLjRDF0qQEWaufIWJR98DbSuTJolqlTlS?= =?us-ascii?q?BuvpcJMoyRz77Fyy8LFgNOeBv3BB7MOx5J1O/+TW0CoK23lxBsWZ3XuKSjgtzG?= =?us-ascii?q?wNTj4ymqt4pB4kkwvR4e1Dm/VdUOdrybZRSA5jbMzTyuV7D5b5XQeTJo7UGmbj?= =?us-ascii?q?ec2vBHQKdvx0w9IKZBwjSdCrjxSGwiPyRrFMyOTNC5sz/abRmXP2IpQlxg=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQClI+1ahqrZVdFcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQlF2MVEwqDJT+BHYJQkQiBeYEPgUCTWAsjhEkCgjEHGQcBBDMVAQI?= =?us-ascii?q?BAQEBAQEBAQETAQEBCAsLCCgjDEIOAYFkJIJPAQEBAQIBDBIFHQEbEgsBAwELB?= =?us-ascii?q?gMCCwMXHQICIQEBEQEFAQoSBhMICoRpAQMNCA+NI5AAPIsFgX8FAReCcAWDUgo?= =?us-ascii?q?ZJgMKVFeCMAIGEogTghODG0o1gk83ghqCU4JUAoYOCIZdin8sCIVlhWuCfV1YP?= =?us-ascii?q?IYBhGuJQkmGLg8DHoEEDCaBdDMaI1AxghIJgWckDA4Jg0WBPok0HzCFXYgOKoI?= =?us-ascii?q?cAQE?= X-IPAS-Result: =?us-ascii?q?A0DhAQClI+1ahqrZVdFcGgEBAQEBAgEBAQEIAQEBAYQlF2M?= =?us-ascii?q?VEwqDJT+BHYJQkQiBeYEPgUCTWAsjhEkCgjEHGQcBBDMVAQIBAQEBAQEBAQETA?= =?us-ascii?q?QEBCAsLCCgjDEIOAYFkJIJPAQEBAQIBDBIFHQEbEgsBAwELBgMCCwMXHQICIQE?= =?us-ascii?q?BEQEFAQoSBhMICoRpAQMNCA+NI5AAPIsFgX8FAReCcAWDUgoZJgMKVFeCMAIGE?= =?us-ascii?q?ogTghODG0o1gk83ghqCU4JUAoYOCIZdin8sCIVlhWuCfV1YPIYBhGuJQkmGLg8?= =?us-ascii?q?DHoEEDCaBdDMaI1AxghIJgWckDA4Jg0WBPok0HzCFXYgOKoIcAQE?= X-IronPort-AV: E=Sophos;i="5.49,364,1520895600"; d="scan'208,217";a="264398437" Received: from mail-ua0-f170.google.com ([209.85.217.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 05 May 2018 05:24:47 +0200 Received: by mail-ua0-f170.google.com with SMTP id f3so15278476uan.9 for ; Fri, 04 May 2018 20:24:47 -0700 (PDT) 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=x6XE4nhLz+5OvKuue88FA09Mqhjdr5euazRX9nmvWho=; b=Am4W2mxlcTksiSV3ThuMYX9TJDJKCfxex065IQULA840zAxknMl4TMlOWu7/cXfGQG zpfDl+b8BTrNCLe+lKPQ0gUiVA5L1mwORxe9mrcnuzE4ZqqSZxkjrfBoq7vSwLh65g14 1W9JRTefmC0/OOh4fsIPPOCUVUg3StoKGkTkbi4+x24VQoh/msn3iIxlgOnH1POA+yZq 4G34AB622W1vlQK3WfR+Qls1AjGxaVxMJz8z9v8UFESjaS73i3IVqwJMqUpouAnI/PmD ZkmKA1QLugc3BwtRgyI8OBYAEQlnPXC2yd07kTuY9slm1VkutUaFg0EThp3Q/SIsTYPk VoQg== 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=x6XE4nhLz+5OvKuue88FA09Mqhjdr5euazRX9nmvWho=; b=Z+zQOkOHv35NLN1NpCV+x8Rc3Yu2cHg+GNKPVicqtv8nTT6OQg5dviB5CuCgcqrgWs yFNhFJS5n0gpOpbOFlUBYSH/vcXTZ9J7brSpzV89mq40TmVDd/D6iverko1Xtm98Xayx u0GgFZgT752pvQ0gGFebew867coy4hsuVHg09aca5QLOep2TJL8dOrwsABhAX1YBLQYB AxdI4lt1vzjoiXeqPp5iyScKB0HDgNkfkGxkwo0vJD0/nwA9eQ78kQlsWbig6Tcg7h/Q 5l3LYn4rJ/EXT16N9rNYu4jA6M9sWiJ4sLUEWqkch0AKBpfG0WP7B+vJqf3M1j/sHyS6 ZGOw== X-Gm-Message-State: ALQs6tBLmvW+tCxHtax/2CS7/0Ti0Sz2BLLmSzVH9NbDOAsWrm90bJzf mFWO7MQhBgeOkhAGfRzVzojHIt9CRU7byAElPeE= X-Google-Smtp-Source: AB8JxZq02PIND/54wW1rBKnCBZ9KfSx8GPlz0e4PipD4ygMStcbw1j11BdCU3BP1/SN6rm/0Hbokh8NB7xx4I5Wa2Rw= X-Received: by 10.176.78.174 with SMTP id l46mr28120565uah.61.1525490686034; Fri, 04 May 2018 20:24:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.97.134 with HTTP; Fri, 4 May 2018 20:24:45 -0700 (PDT) In-Reply-To: References: From: Chet Murthy Date: Fri, 4 May 2018 20:24:45 -0700 Message-ID: To: Frederic Perriot Cc: caml-list Content-Type: multipart/alternative; boundary="f403043ee9087306ac056b6cfa1c" Subject: Re: [Caml-list] an implicit GC rule? Reply-To: Chet Murthy X-Loop: caml-list@inria.fr X-Sequence: 16873 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --f403043ee9087306ac056b6cfa1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Frederic, It's been a while since I did this sort of thing, but I suspect if you declare CAMLlocal variables for each intermediate expression, and stick in the assignments, that should solve your problem (while not making your code too ugly). E.g. CAMLprim value left_comb(value a, value b, value c) { CAMLparam3(a, b, c); CAMLlocal5(l1, l2, l3, l4, l5); CAMLreturn(l1 =3D Tree(l2 =3D Tree((l3 =3D Leaf(a)), (l4 =3D Leaf(b)), = (l5 =3D Leaf(c)))); } Even better, you could linearize the tree of expressions into a sequence, and that should solve your problem, also. Uh, I think. Been a while since I wrote a lotta C/C++ code to interface with Ocaml, but this oughta work. --chet-- On Wed, May 2, 2018 at 9:09 AM, Frederic Perriot wrote: > Hello caml-list, > > I have a GC-related question. To give you some context, I'm writing a > tool to parse .cmi files and generate .h and .c files, to facilitate > constructing OCaml variants from C bindings. > > For instance, given the following source: > > type 'a tree =3D Leaf of 'a | Tree of 'a tree * 'a tree [@@h_file] > > > the tool produces C functions: > > CAMLprim value Leaf(value arg1) > { > CAMLparam1(arg1); > CAMLlocal1(obj); > > obj =3D caml_alloc_small(1, 0); > > Field(obj, 0) =3D arg1; > > CAMLreturn(obj); > } > > CAMLprim value Tree(value arg1, value arg2) > { > // similar code here > } > > > From there, it's tempting to nest calls to variant constructors from C > and write code such as: > > CAMLprim value left_comb(value a, value b, value c) > { > CAMLparam3(a, b, c); > CAMLreturn(Tree(Tree(Leaf(a), Leaf(b)), Leaf(c))); > } > > > The problem with the above is the GC root loss due to the nesting of > calls to allocating functions. > > Say Leaf(c) is constructed first, and the resulting value cached in a > register, then Leaf(b) triggers a collection, thus invalidating the > register contents, and leaving a dangling pointer in the top Tree. > > Here is an actual ocamlopt output, with Leaf(c) getting cached in rbx: > > 0x000000000040dbf4 <+149>: callq 0x40d8fd > 0x000000000040dbf9 <+154>: mov %rax,%rbx > 0x000000000040dbfc <+157>: mov -0x90(%rbp),%rax > 0x000000000040dc03 <+164>: mov %rax,%rdi > 0x000000000040dc06 <+167>: callq 0x40d8fd > 0x000000000040dc0b <+172>: mov %rax,%r12 > 0x000000000040dc0e <+175>: mov -0x88(%rbp),%rax > 0x000000000040dc15 <+182>: mov %rax,%rdi > 0x000000000040dc18 <+185>: callq 0x40d8fd > 0x000000000040dc1d <+190>: mov %r12,%rsi > 0x000000000040dc20 <+193>: mov %rax,%rdi > 0x000000000040dc23 <+196>: callq 0x40da19 > 0x000000000040dc28 <+201>: mov %rbx,%rsi > 0x000000000040dc2b <+204>: mov %rax,%rdi > 0x000000000040dc2e <+207>: callq 0x40da19 > > > While the C code clearly violates the spirit of the GC rules, I can't > help but feel this is still a pitfall. > > Rule 2 of the manual states: "Local variables of type value must be > declared with one of the CAMLlocal macros. [...]" > > But here, I'm not declaring local variables, unless you count compiler > temporaries as local variables? > > I can see some other people making the same mistake I did. Should > there be an explicit warning in the rules? maybe underlining that > compiler temps count as variables, or discouraging the kind of nested > calls returning values displayed above? > > thanks, > Fr=C3=A9d=C3=A9ric Perriot > > PS: this is also my first time posting to the list, so I take this > opportunity to thank you for the great Q's and A's I've read here over > the years > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --=20 Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs= --f403043ee9087306ac056b6cfa1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Frederic,

It's been a while since I= did this sort of thing, but I suspect if you declare CAMLlocal variables f= or each intermediate expression, and stick in the assignments, that should = solve your problem (while not making your code too ugly).=C2=A0 E.g.
<= div>
CAMLprim value left_comb(value a, value b, value c)=
{
=C2=A0 =C2=A0 CAMLparam3(a, b, c);
=C2=A0 = CAMLlocal5(l1, l2, l3,=C2=A0 l4, l5);
=C2=A0 =C2=A0 CAMLreturn(l1= =3D Tree(l2 =3D Tree((l3 =3D Leaf(a)), (l4 =3D Leaf(b)), (l5 =3D Leaf(c)))= );
}

Even better, you could linear= ize the tree of expressions into a sequence, and that should solve your pro= blem, also.

Uh, I think.=C2=A0 Been a while since = I wrote a lotta C/C++ code to interface with Ocaml, but this oughta work.

--chet--


On Wed, May 2, 2018 at 9:09 AM, F= rederic Perriot <fperriot@gmail.com> wrote:
Hello caml-list,

I have a GC-related question. To give you some context, I'm writing a tool to parse .cmi files and generate .h and .c files, to facilitate
constructing OCaml variants from C bindings.

For instance, given the following source:

type 'a tree =3D Leaf of 'a | Tree of 'a tree * 'a tree [@@= h_file]


the tool produces C functions:

CAMLprim value Leaf(value arg1)
{
=C2=A0 =C2=A0 CAMLparam1(arg1);
=C2=A0 =C2=A0 CAMLlocal1(obj);

=C2=A0 =C2=A0 obj =3D caml_alloc_small(1, 0);

=C2=A0 =C2=A0 Field(obj, 0) =3D arg1;

=C2=A0 =C2=A0 CAMLreturn(obj);
}

CAMLprim value Tree(value arg1, value arg2)
{
=C2=A0 // similar code here
}


>From there, it's tempting to nest calls to variant constructors from C<= br> and write code such as:

CAMLprim value left_comb(value a, value b, value c)
{
=C2=A0 =C2=A0 CAMLparam3(a, b, c);
=C2=A0 =C2=A0 CAMLreturn(Tree(Tree(Leaf(a), Leaf(b)), Leaf(c)));
}


The problem with the above is the GC root loss due to the nesting of
calls to allocating functions.

Say Leaf(c) is constructed first, and the resulting value cached in a
register, then Leaf(b) triggers a collection, thus invalidating the
register contents, and leaving a dangling pointer in the top Tree.

Here is an actual ocamlopt output, with Leaf(c) getting cached in rbx:

=C2=A0 =C2=A00x000000000040dbf4 <+149>:=C2=A0 =C2=A0 callq=C2=A0 0x40= d8fd <Leaf>
=C2=A0 =C2=A00x000000000040dbf9 <+154>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%rbx
=C2=A0 =C2=A00x000000000040dbfc <+157>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= -0x90(%rbp),%rax
=C2=A0 =C2=A00x000000000040dc03 <+164>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%rdi
=C2=A0 =C2=A00x000000000040dc06 <+167>:=C2=A0 =C2=A0 callq=C2=A0 0x40= d8fd <Leaf>
=C2=A0 =C2=A00x000000000040dc0b <+172>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%r12
=C2=A0 =C2=A00x000000000040dc0e <+175>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= -0x88(%rbp),%rax
=C2=A0 =C2=A00x000000000040dc15 <+182>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%rdi
=C2=A0 =C2=A00x000000000040dc18 <+185>:=C2=A0 =C2=A0 callq=C2=A0 0x40= d8fd <Leaf>
=C2=A0 =C2=A00x000000000040dc1d <+190>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %r12,%rsi
=C2=A0 =C2=A00x000000000040dc20 <+193>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%rdi
=C2=A0 =C2=A00x000000000040dc23 <+196>:=C2=A0 =C2=A0 callq=C2=A0 0x40= da19 <Tree>
=C2=A0 =C2=A00x000000000040dc28 <+201>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rbx,%rsi
=C2=A0 =C2=A00x000000000040dc2b <+204>:=C2=A0 =C2=A0 mov=C2=A0 =C2=A0= %rax,%rdi
=C2=A0 =C2=A00x000000000040dc2e <+207>:=C2=A0 =C2=A0 callq=C2=A0 0x40= da19 <Tree>


While the C code clearly violates the spirit of the GC rules, I can't help but feel this is still a pitfall.

Rule 2 of the manual states: "Local variables of type value must be
declared with one of the CAMLlocal macros. [...]"

But here, I'm not declaring local variables, unless you count compiler<= br> temporaries as local variables?

I can see some other people making the same mistake I did. Should
there be an explicit warning in the rules? maybe underlining that
compiler temps count as variables, or discouraging the kind of nested
calls returning values displayed above?

thanks,
Fr=C3=A9d=C3=A9ric Perriot

PS: this is also my first time posting to the list, so I take this
opportunity to thank you for the great Q's and A's I've read he= re over
the years

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--f403043ee9087306ac056b6cfa1c--