all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Conservative GC isn't safe
Date: Mon, 28 Nov 2016 17:55:00 +0200	[thread overview]
Message-ID: <83inr7zjjf.fsf@gnu.org> (raw)
In-Reply-To: <1CB11DFF-E6C2-4A1B-BE7E-8877DC38DB0A@raeburn.org> (message from Ken Raeburn on Mon, 28 Nov 2016 04:36:56 -0500)

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 28 Nov 2016 04:36:56 -0500
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> But we do use interior pointers sometimes; looking at Fsubstring’s handling of a vector object:
> 
>   else
>     res = Fvector (ito - ifrom, aref_addr (string, ifrom));
> 
>   return res;
> }
> 
> … here we pass Fvector a pointer to somewhere within the “contents” array of the vector passed as argument “string”; it’s neither the Lisp_Object value, nor the start of the allocated structure.  Now, I don’t think this is a case that can trigger GC at the critical time.  But clearly we’ve got at least one case where we keep an interior pointer and — locally, at least; the caller could be another matter — don’t keep a live handle on the object itself.

But 'string' still references the contents array of the vector, so GC
will mark it when it comes to 'string'.

> And the compiler can do it too.  For example, if we did something like this:
> 
>   DEFUN (“frob-array-elts", Ffrob_array_elts, Sfrob_array_elts, 1, 1, 0,
>          doc: /* Blah */ )
>     (Lisp_Object obj)
>   {
>     int i;
>     for (i = 0; i < 30; i += 3)
>       {
>         frob (AREF (obj, i));
>       }
>     return Qnil;
>   }
> 
> I tried compiling this (“gcc version 4.9.2 (Debian 4.9.2-10)” on x86-64).  The generated code computes obj+3 (vector tag is 5, contents array starts at offset 8) and obj+0xf3 (end of the iteration), and overwrites the register containing the original “obj” value with the argument to be passed to “frob”.
> 
> If, in this case, “frob” were something that could trigger GC, then stack scanning would not see “obj”, at least not in this stack frame.  And if the caller is doing something like:
> 
>   Ffrob_array_elts (get_vector_of_stuff ());
> 
> then the caller needn’t retain any other references to “obj” either.

Again, 'obj' will be somewhere on the stack up the call frames.
Otherwise, how did it wind up in your frob-array-elts function?



  reply	other threads:[~2016-11-28 15:55 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 [this message]
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
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=83inr7zjjf.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=raeburn@raeburn.org \
    /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.