[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failing to GC killed buffers considered harmful
From: |
Stefan Monnier |
Subject: |
Re: Failing to GC killed buffers considered harmful |
Date: |
Tue, 31 Mar 2020 15:20:03 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
>> > 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
- Re: Failing to GC killed buffers considered harmful, (continued)
- Re: Failing to GC killed buffers considered harmful, Stefan Monnier, 2020/03/30
- Re: Failing to GC killed buffers considered harmful, Stefan Monnier, 2020/03/30
- Re: Failing to GC killed buffers considered harmful, Eli Zaretskii, 2020/03/30
- Re: Failing to GC killed buffers considered harmful, Daniel Colascione, 2020/03/30
- Re: Failing to GC killed buffers considered harmful, Stefan Monnier, 2020/03/30
- Re: Failing to GC killed buffers considered harmful, Eli Zaretskii, 2020/03/31
- Re: Failing to GC killed buffers considered harmful, Eli Zaretskii, 2020/03/31
- Re: Failing to GC killed buffers considered harmful, Pip Cet, 2020/03/31
- Re: Failing to GC killed buffers considered harmful, Stefan Monnier, 2020/03/31
- Re: Failing to GC killed buffers considered harmful, Pip Cet, 2020/03/31
- Re: Failing to GC killed buffers considered harmful,
Stefan Monnier <=