[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conservative GC isn't safe

From: Eli Zaretskii
Subject: Re: Conservative GC isn't safe
Date: Sat, 26 Nov 2016 11:24:38 +0200

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Sat, 26 Nov 2016 01:04:18 -0800
> On 11/26/2016 01:01 AM, Eli Zaretskii wrote:
> >> From: Daniel Colascione <address@hidden>
> >> Date: Sat, 26 Nov 2016 00:33:13 -0800
> >>
> >>>>   2) INTERVAL is GCed, but it's not represented in the memory tree:
> >>>> struct interval isn't a real lisp object and it's allocated as
> >>>> MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval
> >>>> won't protect it from GC. Shouldn't we treat intervals like conses?
> >>>
> >>> Does the code ever create an interval that is accessible only via locals
> >>> when a GC occurs? If not, Emacs should be OK. (This should also be
> >>> documented better.)
> >>
> >> Anywhere in the code? Forever? I wouldn't be confident saying so.
> >
> > A simple practical solution to such assumptions is to add an assertion
> > in some strategic place(s).
> >
> > I don't think it's TRT to sprinkle our sources with code that is there
> > "just in case", i.e. it will never actually run.
> How would you assert dynamically that if an interval is reachable, its 
> owning string or buffer must be too? It's not enough for the variable 
> holding the reference to the string or buffer to be in scope: you have 
> to be sure that the reference isn't dead.

I don't understand the use case you have in mind.  Why would an
interval be created that is not reachable from the interval tree of
some Lisp object?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]