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: Some experience with the igc branch Date: Fri, 27 Dec 2024 17:58:57 +0200 Message-ID: <86a5chw20u.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <87cyhf8xw5.fsf@protonmail.com> <86y103zm4m.fsf@gnu.org> <8734ia79jq.fsf@protonmail.com> <86pllexwru.fsf@gnu.org> <87ldw15h6s.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34459"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 27 16:59:36 2024 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 1tRCkR-0008nP-Ra for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 16:59:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRCjz-0004hz-LU; Fri, 27 Dec 2024 10:59:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRCjv-0004hb-6P for emacs-devel@gnu.org; Fri, 27 Dec 2024 10:59:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRCju-0005cm-9o; Fri, 27 Dec 2024 10:59:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Y9TAGzRS8Q0etty9Y1oqjDfOXCnXMWiFLoezDGEsyNU=; b=ProbUtQosmjq 9+Y3MbhG6vt2RJlgp9o8XrWwszSTngr9xvyAWPKBai4ksL/RwgpsQjNIXsE5drY+k2olblbGMm8fN Mo1iQZddqkeyN10Jc5zNjL/K6+3B+CED9PxGVt61ghhrgLF+VmTpu0kQ3Wv2WXJqxv4W6EVwfGmhm HNCBAHNBKr2nF/efxD7ubR5pWO2zA/pgFYqO99K7Zv2ViPcCQz/jqu+5aGzSV3WoFTiVuTsoO3SFt uu8+rr12OsMA5HfypN2At/EiJ6+g0q0wqbQB4ju1n40p88udD+FWfNEu19iNzt/UHHCo4Q2yddi2Z gs6UVMt+QvQFnQG7IxU60w==; In-Reply-To: <87ldw15h6s.fsf@protonmail.com> (message from Pip Cet on Fri, 27 Dec 2024 14:34:22 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327213 Archived-At: > Date: Fri, 27 Dec 2024 14:34:22 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org > > "Eli Zaretskii" writes: > > > OK, but still, since you wrote the code to implement it, I guess you > > have at least some initial design ideas? I hoped you could describe > > those ideas, so we could better understand what you have in mind, and > > provide a more useful feedback about possible problems, if any, with > > those ideas. > > The idea is that the main thread, after initialization, never calls into > MPS itself. Thanks. I will ask some questions below to understand better what you suggest. > Instead, we create an allocation thread, reacting to messages from the > main thread. > > The allocation thread never actually does anything in parallel with the > main thread: its purpose is to provide a separate stack, not > parallelization. Why is it important to have a separate stack when MPS allocates memory? > All redirected MPS calls wait synchronously for the allocation thread to > respond. > > This includes the MPS SIGSEGV handler, which calls into MPS, so it must > be directed to another thread. MPS SIGSEGV handler is invoked when the Lisp machine touches objects which were relocated by MPS, right? What exactly does the allocation thread do when that happens? > All this makes the previously fast allocation path very slow, and we > need a workaround for that: > > We ensure that we allocate at least 1MB (magic number here) at a time, > then split the area into MPS objects when we need to. The assumption > that we can split MPS allocations is significant but justifiable, > because MPS will be in the same state after two successful back-to-back > allocations and a single allocation combining the two. This seems to rely on some knowledge of MPS internals? But more worrisome: what about "sudden" needs for more that 1MB of memory? For example, C-w in a large buffer needs to allocate a Lisp string for the killed text. > 1. there is no other thread which might trigger a memory barrier (the > allocation thread doesn't) So the allocation thread doesn't GC? If so, who does? If the allocation thread does GC, then how can you ensure it doesn't trigger a barrier? > 3. we don't allocate memory Why can't GC happen when we don't allocate memory? > 4. we don't trigger memory barriers Same question here.