[Top][All Lists]

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

bug#17168: 24.3.50; Segfault at mark_object

From: Daniel Colascione
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Sun, 06 Apr 2014 11:10:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/06/2014 11:00 AM, Richard Stallman wrote:
> You accumulate a list of uninterned symbols whose names are pure.  Why
> make this into a hash table 

To eliminate duplicates, of which there would otherwise be many.

> and then a vector?  

Because that's the best structure to fit in pure storage: the set of
needed symbols never changes, so why *not* turn it into a vector?

> A list should suffice.

No, it really doesn't.

> Or maybe some (or even all) uninterned symbols with pure string names
> should be freed like all other symbols when not pointed to. 

And how do you tell whether they're pointed to without marking the
pointing objects? If you try to mark objects in pure storage, you defeat
the whole point. This change is *exactly* what you need to decide
whether something points to a given symbol.

> check whether the name is pure.

Absolutely not: that's what got us into this mess in the first place.
The purify of a symbol's name should have no bearing on how we treat
that symbol. What matters is whether pure storage refers to an object;
the some of these objects are symbols with pure names is irrelevant.
Please, stop talking about the problem in terms of "symbols whose names
are pure".

Can everyone please stop bikeshedding this? Please read and review the
actual patch instead of suggesting non-solutions. The actual approach is
the simplest general approach that will preserve existing performance
characteristics. The only viable equally simple approach is simply
removing pure storage, and if pure storage works (it amounts to a
primitive kind of generational GC), we might as well keep it.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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