From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New GC concept Date: Tue, 22 Jun 2021 15:59:16 +0300 Message-ID: <837dimukbf.fsf@gnu.org> References: <874ke9h97y.fsf@rfc20.org> <29607b7f-2286-c8c4-a693-cc715a4c26d4@grinta.net> <83k0n5f630.fsf@gnu.org> <10670fe2-0c84-1990-b67b-b1f2215e17cb@dancol.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8138"; mail-complaints-to="usenet@ciao.gmane.io" Cc: daniele@grinta.net, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 22 15:04:17 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lvg4e-0001us-Vt for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Jun 2021 15:04:16 +0200 Original-Received: from localhost ([::1]:34952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvg4d-0005NJ-W3 for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Jun 2021 09:04:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvg0C-0007xF-11 for emacs-devel@gnu.org; Tue, 22 Jun 2021 08:59:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59602) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvg0B-0003po-BV; Tue, 22 Jun 2021 08:59:39 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1027 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvg06-0008LC-8r; Tue, 22 Jun 2021 08:59:37 -0400 In-Reply-To: <10670fe2-0c84-1990-b67b-b1f2215e17cb@dancol.org> (message from Daniel Colascione on Mon, 21 Jun 2021 15:58:20 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270981 Archived-At: > Cc: emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 21 Jun 2021 15:58:20 -0700 > > > 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? The DPMI provider which comes with DJGPP supports DPMI 0.9 with some extensions. (If one runs a DJGPP program on MS-Windows, one gets what Windows provides instead, which is DPMI 0.9.) > 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. Yes, this is supported. > 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 DJGPP has mprotect. It indeed requires DPMI 1.0, but it is also one of the extensions supported by the DPMI provider that comes with DJGPP. > 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. Right, this requires DPMI 1.0. > 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. Yes, definitely.