From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Tue, 29 Nov 2016 03:49:59 -0500 Message-ID: <59FF2893-0616-4F37-B1DA-A3F15D5BECA5@raeburn.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <805F5A19-BFAF-4CA4-AAD6-497C6D554830@raeburn.org> <6e5c928f-8130-08a6-d72d-1b64cc022846@cs.ucla.edu> <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> <83inr7zjjf.fsf@gnu.org> <83bmwzzet5.fsf@gnu.org> <781CA5B8-3DEA-43C8-B9C3-AC4AAEA21950@raeburn.org> <834m2rz9f4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480409454 16720 195.159.176.226 (29 Nov 2016 08:50:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 08:50:54 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 09:50:49 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBe7i-00035B-C2 for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 09:50:46 +0100 Original-Received: from localhost ([::1]:35394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBe7m-000668-3T for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 03:50:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBe74-00061L-BD for emacs-devel@gnu.org; Tue, 29 Nov 2016 03:50:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBe71-0007IZ-Qz for emacs-devel@gnu.org; Tue, 29 Nov 2016 03:50:06 -0500 Original-Received: from mail-qk0-x230.google.com ([2607:f8b0:400d:c09::230]:33098) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBe71-0007IB-Hu for emacs-devel@gnu.org; Tue, 29 Nov 2016 03:50:03 -0500 Original-Received: by mail-qk0-x230.google.com with SMTP id x190so167528487qkb.0 for ; Tue, 29 Nov 2016 00:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A4bmsyxJXeDBZ4cwt/lm+CCZxLJzZuANCyM8U56/ZAY=; b=sTGdgfkWdmrG5tmxJ/rYZjdKWTfpVshoaBg8RkYdK7DF5nA7a8M0Qs1TxRT3K5DYsp kRiGq7kCfJCkl2R8udbJeE9PJ4ESgVLo9XN5Fv96GQ2jzKndjTMDQ7pM9BR0+fpO8FjM JOXLGOMGv7uKfYBMYWff/uVjp71SZ3NBDb1GEh9aH4x0D9nlGP/d6PsGKnmQV4dYBCZQ TGqi+asJyRY4C6PWBD8FsNP+9pZXwDTOd8+lqtIWn+9ndNgtMcaozK7UtSWlHXkNW12U Aj44PU2I1Pw/p+bxvQDSR01DlGM8mDx/ah6Vcsok20YJLKXHVwdjOG5QMTUf26bfJ51X qdbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A4bmsyxJXeDBZ4cwt/lm+CCZxLJzZuANCyM8U56/ZAY=; b=dQw19nf6DQ+mmvwTYW5ZoEmnN+vbOq7bX3tAA9gRSqgFgJ08rAqG0IJdR2hqyur6tW H9arQ9YIFw3wbJwMwRIBikql564KHU7Otca10u+ClafqM0776y+MyH5PqFAbLq/m1h2w grtOHHCF/P2N6mBaf/hRP1zIcql/WDkPsh6fhWqkklASGAtzKfVGzfRWLaOTkigAzZFU NoOBO4EsKPkfq47ugO5+eQ+8syMpJ7i8q3QrUe0jJ1nTOsfr1aa4+iOj5eyo4Aj8Zihy rF1uRasbxDNp7WVCGyP7hGKo8YZnQ/xHcgbgq8kBUAsAx4C/R333FOX3LNADqhwU2r5M qkgQ== X-Gm-Message-State: AKaTC025dwA2CbAcyULahWqJmmCx0/SXRLMScxA8xt33JH0ROkRTAeHQgYS7k2aH8S/3FA== X-Received: by 10.55.65.23 with SMTP id o23mr22194352qka.186.1480409401933; Tue, 29 Nov 2016 00:50:01 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id o190sm30488392qke.5.2016.11.29.00.50.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Nov 2016 00:50:00 -0800 (PST) In-Reply-To: <834m2rz9f4.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209709 Archived-At: On Nov 28, 2016, at 14:33, Eli Zaretskii wrote: >=20 >> From: Ken Raeburn >> Date: Mon, 28 Nov 2016 14:09:44 -0500 >> Cc: Stefan Monnier , >> eggert@cs.ucla.edu, >> emacs-devel@gnu.org >>=20 >>>> But after computing "aref_addr (string, ifrom)", it may very well = be >>>> that `string` is dead and the compiler may then decide not to write >>>> it into the stack. >>>=20 >>> It will still be there in the caller. >>=20 >> Not if Fsubstring (or whatever function) is applied directly to the = return value from some other call. >=20 > No, it still will be there. Not anywhere saved by this part of the call chain. > You need to keep in mind how these variables get to Lisp, and for what > purposes. Our code is written for certain purposes, and that mandates > how data flows in the code. If you go high enough up the stack, you > will find every Lisp object value that matters at some level. I=E2=80=99m talking mainly about calls between C functions in Emacs. = Some original data may come from Lisp code, way up the stack, but if = some C routine applies Fdowncase() or Fmapcar() or Fconcat() to the = Lisp-supplied values, and does further manipulation on them, then = we=E2=80=99re dealing with objects generated in the C code and not = referenced by the Lisp stack. >=20 >> As Bj=C3=B6rn described, the caller may not keep it around at all, = just shift it from register to register, and the callee can scribble = over those registers. >=20 > The number of registers is finite, even in the x86_64 architectures. > The compiler cannot keep storing values in registers, because it needs > to leave enough of them available for the next level of function > invocation, about which it knows nothing before that function is > called. Go deep enough, and values will be pushed on the stack > because the compiler needs to free a register. Or they get discarded, when the compiler sees that they=E2=80=99re not = needed any more. Not when they go out of scope, but when they=E2=80=99re = no longer actually used in the function. >> Even if there=E2=80=99s an automatic variable assigned the value, if = it=E2=80=99s not used later, the compiler may optimize it away; I=E2=80=99= ve lost track of how many times GDB has indicated to me that it = recognizes a variable name but at the current point in the code it=E2=80=99= s been optimized out so GDB can=E2=80=99t show it to me. >=20 > The fact that GDB cannot tell you the value, and instead throws the > "optimized out" thing at you, is just a sign that GCC didn't leave > behind enough information for GDB to get its act together, and/or that > GDB has bugs, and/or that DWARF is not expressive enough to cover some > ingenious optimization technique. It doesn't necessarily tell > anything about where the value really is. If anything, it means the > value is not in a register, i.e. likely on the stack (where else?). Bugs in one or more of the tools are certainly possibilities, but there = really are cases where the value just doesn=E2=80=99t exist in any = particular location, memory or register, because it=E2=80=99s not needed = and the registers can be reused for something else.