Re: Failing to GC killed buffers considered harmful

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > buffer text.
>> The buffer text is not stored within the `struct buffer` object, so no.
> struct buffer_text, I meant.

Ah, right.  We do have pointers into that substructure coming from
indirect buffers.  These should all be accompanied by a `base_buffer`
pointer to the head of the `struct buffer`, so it's not 100% crucial
that we take those inner pointers into account, but yes, it does mean
that inner pointers into `struct buffer` are probably more likely than
for other pseudovectors.

Luckily, Paul's code already takes care of inner pointers into
pseudovectors, so we're good in either case.

> Well, I have created temporary buffers to act as, essentially, mutable
> strings. I see no reason I have to kill
> expensively-but-efficiently-implemented mutable strings explicitly
> before having them collected! More seriously, I do think making
> buffers more lightweight would be a good thing, perhaps even having an
> immutable string without text properties/mutable string with gap and
> some buffer properties/full-blown buffer spectrum.

You don't have to convince me.  I just haven't tried to solve this
long-standing need, and it's a can of worms, I think.

> (As I realize someone here usually demands use cases: I'd like to fix
> the hash table printing code to print hashes predictably.  That
> requires sorting their keys by something predictable. Their printed
> presentation is usually good enough, but that requires
> prin1-to-string, which uses a buffer. It's currently too slow.)

Have you tried to profile it to see where the time is spent, to have
a vague idea of what kind of slimming regime we'd need to impose to our
buffers before it becomes tolerable?

In any case, printing-then-sorting doesn't sound like a good plan:
I think it's inherently inefficient.

>> Indeed, my patch doesn't have anything to do with the original problem,
> I don't see how the original problem would fail to be solved by your patch.

Oh, maybe it would, but that was definitely not my motivation.

> Pdumper doesn't dump all objects that survive GC, only those it
> can reach from the heap (plus some collateral damage). So your patch
> restores that requirement precisely, and we can keep the assert()
> unless we decide we want to relax our standards and allow killed
> buffers during the dump.

I think if we want to re-introduce this assert, we should add a matching
test during pdump.


        Stefan