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: Forwording symbols Date: Mon, 17 Jun 2024 20:50:36 +0200 Message-ID: References: <87jziod6yc.fsf@gmail.com> <874j9rcuf6.fsf@gmail.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="7635"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Emacs Devel , Eli Zaretskii To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 17 20:51:25 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 1sJHRs-0001pM-Ol for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Jun 2024 20:51:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJHRE-0001Ah-6q; Mon, 17 Jun 2024 14:50:44 -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 1sJHRC-0001AI-9I for emacs-devel@gnu.org; Mon, 17 Jun 2024 14:50:42 -0400 Original-Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJHRA-0003qi-Hw; Mon, 17 Jun 2024 14:50:42 -0400 Original-Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a689ad8d1f6so570352466b.2; Mon, 17 Jun 2024 11:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718650238; x=1719255038; 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=VUu6EQiLSTxWjGuCeyUMgtYbE2qJgl7lTWGcFjt4h+s=; b=UA8meh2/U+OSQ8CBeWHrw0+2NjmjDy/5ScEcPdswIUZf5PhQ+yelO5ZxYCsy6Mmv/y 1HjWkVP+WgGCTQr5oVY8pBEqVqN66DJi9UiEzxy2wABUrFwpWrFlmfDyJWkLnbrNXT8q kA4587qlFmpsIvdzIWfgHwLpVj6xOaa1RZv1R9c5Kj4V7FNlkFWkCiFgVHcn9Q+Ld9ar grML/bKh73RH1rLQL14sYt3k3GK0ArDL4X3WtgA9HdYBBwKofMHriNU4w329JJnL++v0 jtsLMAEwQDH/OhVXrGcB2xPsxNhpiJW+kRWZ4jj5B0tnOGz9JNjKaiOpLJDdUOdBXj5x DfOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718650238; x=1719255038; 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=VUu6EQiLSTxWjGuCeyUMgtYbE2qJgl7lTWGcFjt4h+s=; b=mI1jdXcgTMIZuOqkCfiTqXfy1/KeQ17a0l1oDKoBik5qROYjbiPbFsxF2SCGfr7SG9 4quLbSsGeqp6dTXsER08o3a39jvwET8ArG50R0uOHApF26pwx0YhDMfnUBCmKys2Dtw9 mQFwGbWkgJEU4gH/Qx9cwlHkL+fusaDWGMLBYn85ANwz0bUsPTtAY9LLvU/EN1/2LaA1 rNkggc33vRGdTS5EP8FJ2TM3SQP//1LWJkt+/4OdNyHA+YWQpLAIaCiggVBHrNIgRNrQ jHV+Wp1vusKbbnLlbNeOiJHXN5T0C4ffIi+WI9W2KFZcoAK5S9xFg4pPDAetYveSz0Cs 9fFQ== X-Forwarded-Encrypted: i=1; AJvYcCUfyRkvFM1xPVjmJnmhNflSlllbmzqkuYRUVe6AGfZsdkIMVCyVVhfWtOpDGiLltO1MShlmyX0wr8+JVkY= X-Gm-Message-State: AOJu0YzQBBEssywGSt5ffrM1TGSS0J/JkoUNUrB+tInMKusdm2FT5vdo 9w82wrk4HvxH+pB18XHJSf/kGzZUuSeINTx0ROMMPCFiykDTUsuoyi8DgA== X-Google-Smtp-Source: AGHT+IH71Wa1dgz06TF/Hm/XcSFFsruNIzOJpAJXNBPBaF3/FglgT5W/b5+4zamnn2SlLRjm1U6Uqw== X-Received: by 2002:a17:907:c283:b0:a6f:709e:523e with SMTP id a640c23a62f3a-a6f709e53dcmr540578966b.50.1718650237800; Mon, 17 Jun 2024 11:50:37 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36d9b.dip0.t-ipconnect.de. [217.227.109.155]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6f56db61e0sm536466566b.49.2024.06.17.11.50.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 11:50:37 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Mon, 17 Jun 2024 20:39:43 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::631; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x631.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, T_SCC_BODY_TEXT_LINE=-0.01 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:320217 Archived-At: Gerd M=C3=B6llmann writes: > Helmut Eller writes: > >> On Mon, Jun 17 2024, Gerd M=C3=B6llmann wrote: >> >>> The whole dumping of these structs looks highly dubious to me, >>> independent of MPS. They are constants, always have been, AFAICT, even >>> from what I remember from the 90s. >> >> The patch below creates the necessary relocs so that no forwarding >> structs end up in the dump. > > Thanks. pushed. > >> >>> Looking forward to the time when the mirror code is gone :-). >> >> I'm not so optimistic. The first collection is very slow: >> >> time ./emacs -batch -f igc--collect >>=20=20=20=20 >> real 0m12.555s >> user 0m11.708s >> sys 0m0.097s > > That's pretty slow, indeed. The version of Emacs I'm currently running, > which is my fork which does not contain your recent changes, and is an > optimized build with -lmps says > > .../emacs/github/igc % /usr/bin/time src/emacs -batch -f igc--collect > 0.25 real 0.14 user 0.11 sys > >> That's not good. Maybe there is some unfixed problem that is causing >> this slowness, but it could also be that MPS simply is so slow for this >> allocation pattern. > > I guess it is what you suspect because I run into an assertion when dumpi= ng: > > Dumping fingerprint: 79b503a407de48b18f4c304971c234d89bf236c259a1e7cd85= 7559f919943b91 > > igc.c:345: Emacs fatal error: assertion failed: h->obj_type =3D=3D IGC_= OBJ_PAD || nbytes >=3D sizeof (struct igc_fwd) > Fatal error 6: Aborted > > That's a build starting from git clean -xdf, optimized, -lmps, and no > native compilation here of course. > > I'll try to debug this, but I think I have to read the new code first a > bit to understand where to start. Anyway, maybe the following gives you a hint already. The abort happens with this backtrace while writing the dump * thread #1, queue =3D 'com.apple.main-thread', stop reason =3D breakpoint = 5.2 frame #0: 0x00000001001e3cf8 bootstrap-emacs`emacs_abort at sysdep.c:23= 91:3 frame #1: 0x00000001003ec57c bootstrap-emacs`ns_term_shutdown(sig=3D6) = at nsterm.m:5889:5 frame #2: 0x00000001001a2dbc bootstrap-emacs`shut_down_emacs(sig=3D6, s= tuff=3D(struct Lisp_Symbol *) $2 =3D 0x0000000100ca5010) at emacs.c:3162:3 frame #3: 0x00000001001a27a4 bootstrap-emacs`terminate_due_to_signal(si= g=3D6, backtrace_limit=3D2147483647) at emacs.c:464:11 frame #4: 0x0000000100399fa4 bootstrap-emacs`igc_assert_fail(file=3D"ig= c.c", line=3D345, msg=3D"h->obj_type =3D=3D IGC_OBJ_PAD || nbytes >=3D size= of (struct igc_fwd)") at igc.c:82:3 frame #5: 0x000000010039cde8 bootstrap-emacs`obj_size(h=3D0x00000001298= 085f8) at igc.c:345:3 frame #6: 0x000000010039cc6c bootstrap-emacs`igc_dump_finish_obj(client= =3D0x0000000129808600, type=3DIGC_OBJ_DUMPED_BUFFER_TEXT, base=3D"", end=3D= "") at igc.c:3721:7 frame #7: 0x0000000100277fc0 bootstrap-emacs`dump_igc_finish_obj(ctx=3D= 0x000000016fdfc3e8) at pdumper.c:910:26 * frame #8: 0x00000001002840d0 bootstrap-emacs`dump_cold_buffer(ctx=3D0x0= 00000016fdfc3e8, data=3D(struct buffer *) $3 =3D 0x000000010e4d3308) at pdu= mper.c:3694:3 here: char * igc_dump_finish_obj (void *client, enum igc_obj_type type, char *base, char *end) { if (client =3D=3D NULL) return end; struct igc_header *out =3D (struct igc_header *) base; if (is_mps (client)) { struct igc_header *h =3D client_to_base (client); if (h->obj_type =3D=3D IGC_OBJ_VECTOR_WEAK) igc_assert ( (type =3D=3D IGC_OBJ_VECTOR && h->obj_type =3D=3D IGC_OBJ_VECTO= R_WEAK) || h->obj_type =3D=3D type); igc_assert (base + obj_size (h) >=3D end); Looks like the client object passed in is bogus (lldb) p *h (igc_header) (obj_type =3D IGC_OBJ_INVALID, hash =3D 128931976, nwords = =3D 1) (lldb)