emacs-devel
[Top][All Lists]
Advanced

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

Re: Collecting markers with MPS


From: Helmut Eller
Subject: Re: Collecting markers with MPS
Date: Wed, 24 Apr 2024 18:21:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Wed, Apr 24 2024, Eli Zaretskii wrote:

>> We don't need it for correctness.  We would unlikely run out of memory.
>
> Are you sure?  Emacs could easily create gobs of markers.  For
> example, if there are buffers with lost of non-ASCII characters, each
> time we need to compute character position from byte position or vice
> versa, we create more markers in the buffer.  In a session that runs
> for weeks, there could be a lot of them, I think.

Maybe those people who run Emacs for weeks can afford new Macbooks so
that they can it run for months :-)

>> We could also provide functions to manually unlink markers from the
>> buffer that programmers could use to keep the slowness in check.
>
> If we can do this manually, we should be able to do it from a timer,
> no?

Yes, but only the programmers know which markers they no longer need.

>> The MPS supports finalization and weak references.  Finalization could
>> tell us which markers are unreferenced.  The problem is that markers
>> stay referenced as long as they are part of the buffer's marker-chain or
>> the undo-list.
>> 
>> That's why we could use weak references here.  If a marker is referenced
>> only through weak references then MPS can collect it.  MPS will also set
>> the weak reference to 0 when the marker has been collected.  So that we
>> know when we no longer can/need to update the marker.
>> 
>> The old GC knows which references are weak; that's what the special code
>> there is for.  For MPS, we somehow need to tell it which references are
>> weak.
>
> So why did you say this will take much more code than in the old GC?

Because I think introducing those weak reference objects in the
marker-chain needs quite a number of changes.  It's like changing a foo*
to a foo**.  Simple conceptually, but many places need to be touched.
Most of the changes should be straightforward, I hope.

Helmut



reply via email to

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