unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Should catchlist elements be marked during GC?
@ 2006-07-13 10:09 Kim F. Storm
  2006-07-13 15:24 ` Stefan Monnier
  2006-07-14  4:07 ` Richard Stallman
  0 siblings, 2 replies; 4+ messages in thread
From: Kim F. Storm @ 2006-07-13 10:09 UTC (permalink / raw)



During GC, we don't explicitly go through the catchlist, marking the
TAG and VAL member of each element.

I just wondered if it is safe to assume that the TAG and VAL members
are always marked due to some other method?

If not 100% sure, it wouldn't cost a lot to mark them explicitly
during GC.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Should catchlist elements be marked during GC?
  2006-07-13 10:09 Should catchlist elements be marked during GC? Kim F. Storm
@ 2006-07-13 15:24 ` Stefan Monnier
  2006-07-13 21:41   ` Kim F. Storm
  2006-07-14  4:07 ` Richard Stallman
  1 sibling, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2006-07-13 15:24 UTC (permalink / raw)
  Cc: emacs-devel

> During GC, we don't explicitly go through the catchlist, marking the
> TAG and VAL member of each element.

What makes you say so?
In Fgarbage_collect I see:

  for (catch = catchlist; catch; catch = catch->next)
    {
      mark_object (catch->tag);
      mark_object (catch->val);
    }

> I just wondered if it is safe to assume that the TAG and VAL members
> are always marked due to some other method?

Actually, it is safe to assume so if we use conservative stack marking
because the catchlist elements are all allocated on the stack, so we
currently mark them redundantly.

The same holds for the handlerlist, the byte stacks, and the backtrace list
(but not for the specpdl array which is not allocated on the stack).

I have a patch to remove this redundant scanning, but keep it for post-22.


        Stefan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Should catchlist elements be marked during GC?
  2006-07-13 15:24 ` Stefan Monnier
@ 2006-07-13 21:41   ` Kim F. Storm
  0 siblings, 0 replies; 4+ messages in thread
From: Kim F. Storm @ 2006-07-13 21:41 UTC (permalink / raw)
  Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> During GC, we don't explicitly go through the catchlist, marking the
>> TAG and VAL member of each element.
>
> What makes you say so?

Since struct catchtag is defined in eval.c, I didn't think alloc.c
would know how to scan the catchlist, so I didn't even bother to check.

> Actually, it is safe to assume so if we use conservative stack marking
> because the catchlist elements are all allocated on the stack, so we
> currently mark them redundantly.

Ah, yes.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Should catchlist elements be marked during GC?
  2006-07-13 10:09 Should catchlist elements be marked during GC? Kim F. Storm
  2006-07-13 15:24 ` Stefan Monnier
@ 2006-07-14  4:07 ` Richard Stallman
  1 sibling, 0 replies; 4+ messages in thread
From: Richard Stallman @ 2006-07-14  4:07 UTC (permalink / raw)
  Cc: emacs-devel

    During GC, we don't explicitly go through the catchlist, marking the
    TAG and VAL member of each element.

Yes we do.  Here's the code from Fgarbage_collect.

  for (catch = catchlist; catch; catch = catch->next)
    {
      mark_object (catch->tag);
      mark_object (catch->val);
    }

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-07-14  4:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-13 10:09 Should catchlist elements be marked during GC? Kim F. Storm
2006-07-13 15:24 ` Stefan Monnier
2006-07-13 21:41   ` Kim F. Storm
2006-07-14  4:07 ` Richard Stallman

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).