From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: weak hash tables Date: Fri, 05 Jul 2024 14:54:13 +0200 Message-ID: References: <-plQctKgNkvp-LJ9ov2QAiXQKxd9V-hI0yz_opRGxQtbknubCjH4rH2-ymgbw_Qr1ZhB1rtlmiEW8XtuIVNr7nR_Yj20AH6WkH6kUGp68g0=@protonmail.com> <_mNcR6ailVKpYHLxgfo_tJlYGeR0AQIzQWluspYYp5_g5pIIKkHLNfFkklQQgOKNiVW8jn8NS3i2dJ7_B2Qyx9v-Dq3MQ9mP8HNL30UWsqY=@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34948"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Eli Zaretskii , Emacs Devel To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 05 14:55:15 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 1sPiT5-0008ot-MB for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jul 2024 14:55:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPiSC-00052N-In; Fri, 05 Jul 2024 08:54:20 -0400 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 1sPiSA-00051x-T2 for emacs-devel@gnu.org; Fri, 05 Jul 2024 08:54:18 -0400 Original-Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sPiS9-0002ED-24; Fri, 05 Jul 2024 08:54:18 -0400 Original-Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-58bac81f39bso2218474a12.2; Fri, 05 Jul 2024 05:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720184055; x=1720788855; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IaRiEq/YPWC4wUa+8W6GCTW7q0CDw46cTA64BvbKNPE=; b=Yb2Kdu7R2LR7MLrwY3hZcF+vdjNY04P8b/lDoNIcF2yQVRC+y7a75h4YfVvdRrPq2z BmagDqQYfWnd92rzxrCtElgIIi8+f0+lZX8Svspgig2ZNwxlk6mdkB0jsE30uvdvbE/X q6Ni++eu365G1msdA0gwjFJfSJFkV0o6PL18xJu5X4ALkP++K3beFPJGc7dTZ979+G1/ SUuBSr3enJOoW49Hw1mA9x+IrAquNWiNDj79iqfvKHj+R/tC1le43WlTtUViGcwItg41 iP4j96iyt7c11tSq5/tBz8HWnkKTL6+y4Tru1Ez9K1WJEKD2Eg6V0lqRdCQaImlRLtjW RBRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720184055; x=1720788855; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IaRiEq/YPWC4wUa+8W6GCTW7q0CDw46cTA64BvbKNPE=; b=XlsWTnBGXu5EgBlWsQIUkJzvCIN5ZfF4N3FTOCIl157uYgkTGcVYc8AABz3HrMhvr9 XV9sqj59mR+EEKeq+yfMjsaDm3vCgwhDX2uQwdbN9VBc4Y0ND4rLN9b+m9LUpa3G9GPy V9X3C5UxOlqekfqrIRafgj5g4frpmh9q9ek84FO28WWsda/yvpVS4CWsH5NW8aXtNekV Wdrcl7/mg/UMdwOfveOoVyeLfWyYH7XviUgFzdpOEPuehFgCLVnOeEeV6prcZ16vrlW6 ggcUEHQ9jzCogV2PMX3jugK0VM4iVuho7sfR9h5fNsNgIVIHiVmVaSkz2JcJpNaPDRwZ h3ug== X-Forwarded-Encrypted: i=1; AJvYcCUlu2LRTlOCIHZSxYG2jsI9CwAsoOGolx11DpdyqFuBxnlrnc+NIhsYBd7k/7Fv+K+EuygmcRWW2rt4/o1VJwzFXeGUnD2frXk0NblneU6SBio= X-Gm-Message-State: AOJu0Yy5eIt+/SQG3JoCjr3CBzXUtcD8r/GTAVi8RwhPstJElrPMSMOx fZo61D2Kl4QbCRW6ULBljr+diSL2DvSp4kw75EDVSVDLVl/m8CUbxFjXgw== X-Google-Smtp-Source: AGHT+IEKwqOiV8v7ZGQ4Adl87OmgpckxaimWTY/uJ+QFV8NdoxquzeGam03pwakI2I/N/tWzxbtG9w== X-Received: by 2002:a05:6402:35d6:b0:58b:e192:361e with SMTP id 4fb4d7f45d1cf-58e59557b99mr3351208a12.12.1720184054649; Fri, 05 Jul 2024 05:54:14 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a3bd.dip0.t-ipconnect.de. [79.227.163.189]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-58fe866155esm572714a12.20.2024.07.05.05.54.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jul 2024 05:54:14 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Fri, 05 Jul 2024 12:08:55 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:321391 Archived-At: Pip Cet writes: > On Friday, July 5th, 2024 at 03:50, Gerd M=C3=B6llmann wrote: >> Pip Cet pipcet@protonmail.com writes: >> >> > > Ah, I thought what you wrote in the other mail was related to the >> > > IA-32 software emulation shit^Wrequirement, sorry. >> > >> > It's both: >> > >> > 1. change the IGC header to be a uint64_t, because bitfields don't alw= ays behave as expected. >> > 2. use the low-order bits to distinguish extended external extra depen= dency headers from ordinary one-word headers. (This fixes the remaining IA3= 2 bug) > > Except that a uint64_t is two 32 bit words, and they both must be > non-aligned. Unbelievable. Was f=C3=BCr ein Schei=C3=9F. > How horrible. At least we've excluded WIDE_EMACS_INT :-) :-) >> Honesty demands that I add that that would also be good for me: I said >> right from the start that I won't maintain anything and lately that I >> really really feel I need to have a break from this MPS stuff, so I'd >> love if you could take over and realize yoiur ideas. > > My priority would be getting the branch merged. If it isn't, it'll > bit-rot, I'm afraid. Could happen, yes. > I realize it's too soon to ask for a final decision on that (which > would be made on merge day, presumably), but I've found myself using > my IGC emacs -Q when my vanilla Emacs is stuck in GC, so it's not like > it doesn't work at all. And, yes, I realize there's a lot of work to > be done for that... (I'm using it all the time, too. I'm running an Emacs from cl-packages (the branch from igc is branched) to run an Emacs from the igc branch under LLDB. The igc Emacs is what I'm using all the time, and in that I develop in yet another branch, which I merge/rebase back to igc.) Wrt to the merge to master, I think the maintainers, mainly Eli probably, have to cope with the situation as it is. As far as I'm concerned, that's solely a GNU thing. > Feature/bug-wise, what's still missing? key-or-value weakness (haven't > slept enough yet to decide whether to merge), sure, but is that > essential? The signal handler stuff is fixable, I'm convinced. I've > got a bug fix for what I hope to be the very last bug with the IA-32 > stuff. There are two very minor bugs (there are Lisp_Objects in the > wrong part of pure space, and igc_realloc_ambig doesn't park the > arena--one-liners really). The two major fixmes concern native > compilation and the byte code stack, right? I'm perfectly happy to > leave unnecessarily ambiguous references ambiguous for now. Curiously enough native compilation seems to work for me now on macOS. I was never able to debug this deep enough to find the underlying cause why it failed. It might be a new version fo GCC 14 that I got meanwhile, the most recent merge from master, changes in igc, or anything else. The scanning of the byte code stack is really ugly, right. The computation of where it ends that is. Mattias mentioned that he might make changes in the byte code stack so that it could be marked exactly. One could just wait till that happens. It doesn't seem to cause stability problems. Other than that I have nothing left in my todo list once I've done the n-th pass of scanning the source code for untraced references Which proceeds slowlym but I've reached the files starting with c now :-). > My next question would be: are there any planned big changes which > would touch too many files on the master branch?=20 Not from my side. I'm through with my stuff. Helmut mentioned interest in remove headers from conses, I think, but I guess he can tell what he wants to do himself better than me :-). (I'm not interested in that, FWIW, but I can understand why some want it.) > The one I can think of is I would like to move the IGC header to live > in struct Lisp_Cons/Lisp_String/Lisp_Symbol/Lisp_Float and in union > vectorlike_header, and make client =3D=3D base. I believe this would also > make things easier for other GC approaches which would also need some > sort of header. No real problem for non-native-comp builds: the > problem with this is changing these structs requires adjusting comp.c, > which rebuilds them in libgccjit calls. I don't think that's very hard > to do either, but it's potentially subtle and I'm planning to write > Andrea about it. > > So, yes, I'd love that too,=20 =F0=9F=91=8D=F0=9F=91=8D=F0=9F=91=8D :-). Thanks! > but I may be underestimating the difficulty of getting this merged. The administrative hurdles, you mean? Could be, no idea.