Re: New GC concept

[Daniel Colascione <dancol@dancol.org>]

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.