[Top][All Lists]

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

Re: New GC concept

From: Daniel Colascione
Subject: Re: New GC concept
Date: Mon, 21 Jun 2021 15:58:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 6/7/21 7:22 PM, Eli Zaretskii wrote:
From: Daniele Nicolodi <daniele@grinta.net>
Date: Mon, 7 Jun 2021 21:51:45 +0200

We can definitely replace the existing GC with the new GC everywhere.
I've designed the new GC to work on systems without virtual memory
facilities. On these systems, we'll have to run the GC in
non-concurrent, non-generational mode, but that's no regression from
what we have today. We'll also probably want to use a smaller block size
on these systems to reduce fragmentation overhead.
Isn't DOS the only system in this class? (It is not a rhetorical
question: a while ago I asked which systems are officially supports and
the answer was that all systems that currently run Emacs are supported).

Does it make sense to still support DOS?
The development environment which is used to build the MS-DOS port of
Emacs (DJGPP) does support virtual memory (IIUC what that means in
this context).

Oh, right. I completely forgot that we have DPMI.

It's been a very long time since I looked at that. Does DJGPP provide DPMI 0.9 or 1.0?

To get generational GC under DJGPP, we'll need something like a SIGSEGV handler, a bit of code that we run when the CPU signals a memory protection fault. I think we get there by installing an exception interrupt handler, as in http://www.delorie.com/djgpp/doc/dpmi/ch4.5.html, and I think it'll work in both DPMI 0.9 and 1.0. Another thing we need for generational GC is the ability to mark a range of pages read-only, as with mprotect. I think DPMI gives us the ability to change page permissions, but 0.9 does not. See http://www.delorie.com/djgpp/doc/dpmi/api/310507.html

The other thing we get with VM is the ability to swap the from-space and the to-space without an additional memory copy. DPMI 1.0 appears to provide a shared memory facility that would let us do that (the equivalent of mmap/MapViewOfFile of an anonymous segment), but I'm not sure that DPMI 0.9 gives us that ability.

Anyway, even if it is theoretically possible to implement the new GC's fancy VM stuff in terms of DPMI, I think it should have lower priority than the rest of the system. The new GC run without virtual memory use at all should still be no worse overall than the current GC, so MS-DOS Emacs at least wouldn't see a regression if we switched to a version of the new GC that didn't understand DPMI.

But DPMI support for the new GC would definitely be a fun retro computing project.

reply via email to

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