unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: herring@lanl.gov
Cc: Alin Soare <as1789@gmail.com>, Emacs Dev <emacs-devel@gnu.org>
Subject: Re: please help concerning specpdl
Date: Tue, 14 Dec 2010 19:53:20 -0500	[thread overview]
Message-ID: <F9B1DA2C-90CF-4D23-8B37-16DEC5129B16@raeburn.org> (raw)
In-Reply-To: <60550.130.55.118.19.1292372090.squirrel@webmail.lanl.gov>

On Dec 14, 2010, at 19:14, Davis Herring wrote:
>> I see that GCPROx macros are used to protect the variables of type Lisp
>> Object on the stack of C code (that the compiler creates), not to protect
>> the lisp objects in specpdl. The GCPRO protection is against the algorthm
>> of conservative stack. Am I right ?
> 
> I believe the GCPRO draws the attention of the stack checker to those Lisp
> objects to make sure that they're not collected.

The Lisp engine and the garbage collection code have undergone some revision over the years, and support a few different configurations based on the machine architecture and operating system support.  See, for example, the comment discussing GC_MARK_STACK in lisp.h.  GCPRO macros are used to keep track of Lisp_Object variables on the C stack in case conservative stack scanning is not used.  If conservative stack scanning is used, you can make GCPRO macros be no-ops, or you can instrument them to compare the effectiveness of the two techniques.

But in terms of writing C code, you should assume that the GCPRO machinery is required.

(Well, that's not 100% true.  If any code path that can result in the garbage collector being called either doesn't care about a particular object any more, or can guarantee that the object will be visible to the garbage collector through some other path, then it needn't be recorded with GCPRO.  But it's probably better to be conservative if you're not completely certain.)

Ken


      reply	other threads:[~2010-12-15  0:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-04  5:33 please help concerning specpdl Alin Soare
2010-12-06 16:22 ` Davis Herring
2010-12-14 21:25   ` Alin Soare
2010-12-15  0:14     ` Davis Herring
2010-12-15  0:53       ` Ken Raeburn [this message]

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=F9B1DA2C-90CF-4D23-8B37-16DEC5129B16@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=as1789@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=herring@lanl.gov \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).