all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Conservative GC isn't safe
Date: Tue, 29 Nov 2016 03:49:59 -0500	[thread overview]
Message-ID: <59FF2893-0616-4F37-B1DA-A3F15D5BECA5@raeburn.org> (raw)
In-Reply-To: <834m2rz9f4.fsf@gnu.org>

On Nov 28, 2016, at 14:33, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Mon, 28 Nov 2016 14:09:44 -0500
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>> eggert@cs.ucla.edu,
>> emacs-devel@gnu.org
>> 
>>>> 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.
>>> 
>>> It will still be there in the caller.
>> 
>> Not if Fsubstring (or whatever function) is applied directly to the return value from some other call.
> 
> 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’m 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’re dealing with objects generated in the C code and not referenced by the Lisp stack.

> 
>> As Björn 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.
> 
> 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’re not needed any more.  Not when they go out of scope, but when they’re no longer actually used in the function.

>> Even if there’s an automatic variable assigned the value, if it’s not used later, the compiler may optimize it away; I’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’s been optimized out so GDB can’t show it to me.
> 
> 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’t exist in any particular location, memory or register, because it’s not needed and the registers can be reused for something else.




  reply	other threads:[~2016-11-29  8:49 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-26  8:11 Conservative GC isn't safe Daniel Colascione
2016-11-26  8:30 ` Paul Eggert
2016-11-26  8:33   ` Daniel Colascione
2016-11-26  9:01     ` Eli Zaretskii
2016-11-26  9:04       ` Daniel Colascione
2016-11-26  9:24         ` Eli Zaretskii
2016-11-26 15:05         ` Stefan Monnier
2016-11-26 15:21           ` Camm Maguire
2016-11-28 17:51           ` Daniel Colascione
2016-11-28 18:00             ` Eli Zaretskii
2016-11-28 18:03               ` Daniel Colascione
2016-11-28 18:50                 ` Eli Zaretskii
2016-11-28 18:03             ` Stefan Monnier
2016-11-28 19:18               ` Daniel Colascione
2016-11-28 19:33                 ` Stefan Monnier
2016-11-28 19:37                 ` Eli Zaretskii
2016-11-28 19:40                   ` Daniel Colascione
2016-11-28 20:03                     ` Eli Zaretskii
2016-11-28 20:09                       ` Daniel Colascione
2016-11-28 19:26               ` Andreas Schwab
2016-11-28 19:34                 ` Stefan Monnier
2016-11-26 15:03   ` Stefan Monnier
2016-11-26 15:12     ` Eli Zaretskii
2016-11-26 16:29       ` Stefan Monnier
2016-11-26 16:42         ` Eli Zaretskii
2016-11-26 18:43           ` Stefan Monnier
2016-11-27  6:17     ` Ken Raeburn
2016-11-27 15:39       ` Eli Zaretskii
2016-11-28  9:50         ` Ken Raeburn
2016-11-28 15:55           ` Eli Zaretskii
2016-11-27 16:15       ` Paul Eggert
2016-11-28  9:36         ` Ken Raeburn
2016-11-28 15:55           ` Eli Zaretskii
2016-11-28 16:15             ` Stefan Monnier
2016-11-28 17:37               ` Eli Zaretskii
2016-11-28 17:49                 ` Stefan Monnier
2016-11-28 17:57                   ` Eli Zaretskii
2016-11-28 18:05                     ` Stefan Monnier
2016-11-28 19:09                 ` Ken Raeburn
2016-11-28 19:33                   ` Eli Zaretskii
2016-11-29  8:49                     ` Ken Raeburn [this message]
2016-11-28 17:03             ` Björn Lindqvist
2016-11-28 16:13           ` Paul Eggert
2016-11-27 16:52       ` Stefan Monnier
2016-11-26 19:08 ` Pip Cet
2016-11-27  0:24   ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59FF2893-0616-4F37-B1DA-A3F15D5BECA5@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.