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: Sat, 06 Jul 2024 08:51:00 +0200 Message-ID: References: <878qyf4sgm.fsf@gmail.com> <4JQ7mGAwBrGOLmq0SzqnMOSkzoEFxTOfGHxGzJ8fa48FMVlfasV4QTPgE3E8yidy4XXamrIt3gg9Lv_TSJkOO5IIz4VDmygEtBAEsvhIusM=@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="14778"; 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 Sat Jul 06 08:51:23 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 1sPzGV-0003hJ-N5 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jul 2024 08:51:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPzGI-0004Oi-Mh; Sat, 06 Jul 2024 02:51:10 -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 1sPzGF-0004OV-KB for emacs-devel@gnu.org; Sat, 06 Jul 2024 02:51:08 -0400 Original-Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sPzGC-00062x-Iu; Sat, 06 Jul 2024 02:51:07 -0400 Original-Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-57cc30eaf0aso1390869a12.2; Fri, 05 Jul 2024 23:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720248661; x=1720853461; 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=pWE5OaTHpzmXj/YlejK3M4baE8Por4FW1km7hdca2t8=; b=fF4KtklMxpdnHyNTqSVNMLOM81kMh7D4pedgVuKSi6A+tw8fYGXHP7TQu3rMUMRdwT CXcOcaqjYvDn95HPB1lvV+inZr0qBGsszjhtHiRQH56mrZtezZuK9ImHaugip+9r4azE aRVAkGpB7Er5XPODNHmbXmSml/Pr+RJPbg+gyNiAM5GUKMvTU0fI4kNUsIrD4c7GJJaQ vxPRT1StA8h8EdJTkVgPPiIlYepZWsSV00xvFr60FrnHsM8OjzqqYVkWLvMYVZU16Tyv giFrPmP+pVCYKH/8QCdMdOIe0SzG4Qpx5JuDSQgVO5Te4tQesX8+xLf5QDc+FwneqWgN pBog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720248661; x=1720853461; 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=pWE5OaTHpzmXj/YlejK3M4baE8Por4FW1km7hdca2t8=; b=RcVOnJiO0+CMVh/XiJ5KXZYW7pRbkd/bLio7p9h2A8cUoadfNkRVQjIITlyKhHoWw0 TDpZdsI7CV2kZ3utZ7k9ForfBuuZJJC6zZlxp8Uduo88NHjtaXroRv/D6jrxexuBkZAB 6JfGm278LYmTmOU2ye0Q05262Rj6JS+m1dJM+hLwUKJaYsY7Mnz+KyoOiX/95xt9M3gG WAoBGCe40Yb4+xXuYNU/u7f6fFTlAlR6n1mWuQJEEH/JDA8FC/PMbYbK5Nhf8kmdb60v +etjJLk4MAfr2fc7rC7mM/BNZyuNYHWjOj+cOHb5zhrCFgOtoScECpBe4m6YiCcFx5zH cw+w== X-Forwarded-Encrypted: i=1; AJvYcCVM2kgvmULID0vY+Kz+5hS7nb8QP5UvNAzCxSEr5f69hwt2uD19jiDhgCQNHcrsI3T0y/SchcEONl9wkA7bI+bJBMEsgb6JK1N0UeiFv9fieWs= X-Gm-Message-State: AOJu0YzvGBLFMbcLVB4fckb7jTnH3PsUPkAG3s7c1/WN+xd0NhQRGqZB jGykWAYVI8ivGfTpi/2+CRtZkRu0GwS2hihoCVAIfJXz4LzDXSlL49nwBw== X-Google-Smtp-Source: AGHT+IEPfM1wENC8tzHLAzUBoK3tZgfaFkU3K5cAse9d18Evv9PsYlfLRLTzKNa59M8DvqiDdRgzrw== X-Received: by 2002:a05:6402:3510:b0:57d:42f6:63fe with SMTP id 4fb4d7f45d1cf-58e5a4fe973mr6700282a12.22.1720248661300; Fri, 05 Jul 2024 23:51:01 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a82e.dip0.t-ipconnect.de. [79.227.168.46]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5861324feb7sm10549789a12.37.2024.07.05.23.51.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jul 2024 23:51:00 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Sat, 06 Jul 2024 06:29:05 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52f.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:321413 Archived-At: Pip Cet writes: > On Saturday, July 6th, 2024 at 06:20, Gerd M=C3=B6llmann wrote: >> Pip Cet pipcet@protonmail.com writes: >>=20 >> > On Saturday, July 6th, 2024 at 03:39, Gerd M=C3=B6llmann gerd.moellman= n@gmail.com wrote: >> >=20 >> > > Pip Cet pipcet@protonmail.com writes: >> > >=20 >> > > > What I'm doing right now is alternating usleep(10000) and >> > > > igc_collect() in a secondary thread. That crashes somewhat >> > > > reproducibly in interactive sessions. >> > >=20 >> > > Could you please make that available in some form? >> >=20 >> > Sure. I was thinking about cleaning it up (usleep is non-standard) and >> > committing it behind a stress-test option, actually. >>=20 >> Thanks! If it's not too bad performance-wise, I was thinking of running >> it in the Emacs I'm normally using, in parallel to the rest. > > It is very bad since full GCs stop the main thread. However, running > it once a second is enough to find some bugs and GCs are fairly > fast... Ok, thanks. I'll give it a spin when it's there. Alas, my Emacs is already pretty slow because of of -O0 and --enable-checking=3Dall,igc_debug. Maybe I can trade something of that in for the igc-collect. > (One thing I've noticed is that MPS handles failed scans gracefully; > we might be able to get away with "interrupting" a scan if inputs or > signals are pending, but correctness first...) > >> > Right now it's dying because specpdl is a union type and GC might hit >> > while the main thread leaves it in a partially-initialized state. I >> > vaguely recall turning it into a struct for that reason on another >> > branch years ago... >>=20 >> Shit. That could mean that we have to scan specpdl amiguously. > > I was hoping to avoid that. Maybe it's enough to just clear the pdl > entries in between modifications, since the values we put in should be > on the stack or in registers and be pinned. I tried to do something in umbind_to already, which is not 100% safe I think (there's a tiny window left, I guess). But I find it more likely it happens in specbind, when we fill out a new entry. Maybe we should memclr the entry there for the case that the entry type is filled out before the rest is valid. Hm.