[Top][All Lists]

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

Re: Conservative GC isn't safe

From: Paul Eggert
Subject: Re: Conservative GC isn't safe
Date: Mon, 28 Nov 2016 08:13:53 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/28/2016 01:36 AM, Ken Raeburn wrote:
here we pass Fvector a pointer to somewhere within the “contents” array of the 
vector passed as argument “string”

Sure, but in practice there are always other copies of 'string' floating around. Look at the call to Fsubstring in bytecode.c, for example:

  TOP = Fsubstring (TOP, v1, v2);

There's another copy of 'string' in the stack. Even if that code were changed to this:

  Lisp_Object v = POP; PUSH (Fsubstring (v, v1, v2));

Because the garbage collector doesn't know where the stack top is and so scans the entire stack, the GC would still mark the string.

In practice, Emacs C code doesn't create objects that no Elisp code cares about, and then mess with those objects in a way that can cause GC and that does not need the object base address. Partly this is due to the longstanding tradition where such objects needed to be GCPRO'd anyway. Partly it's because it's the Emacs C code is designed to be subsidiary to the Lisp code, and it's unusual to create and mess with objects not intended to be exported to Lisp.

If Emacs code starts doing what you're worried about, then we'll have to modify the GC marker to chase all pointers into objects, not merely base pointers. But I don't see this being a problem in the current code.

reply via email to

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