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: Some experience with the igc branch Date: Wed, 25 Dec 2024 05:56:26 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> 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="15394"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 05:56:53 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 1tQJRz-0003pM-PM for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 05:56:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQJRi-00080x-RD; Tue, 24 Dec 2024 23:56:35 -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 1tQJRg-00080l-Pz for emacs-devel@gnu.org; Tue, 24 Dec 2024 23:56:33 -0500 Original-Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQJRf-0005Ld-2D; Tue, 24 Dec 2024 23:56:32 -0500 Original-Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aaeecbb7309so214656866b.0; Tue, 24 Dec 2024 20:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735102588; x=1735707388; 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=QAZfSqVelueRAFHKq9hc0nxhbkTJuiO+q7f+eynL8Yc=; b=TiRv6KP0Q8ekLaasGa8uOFGngKtmTjnQCPUI63VNVulhZFNuiZCR/GxReS7FN96p+q MkSoSiJD+h3PMIeCEGOzN1ERS3TdXgdBjxfceNGfNdrFfD7C8VO0TuRqxYznkFHhY0tf dt3gf1KEhlg0xdR60/vex7kpoB8foRGaZQyd003xVKj98PpCFqWp+G56l0mCBmb2oCKj d4vZY6cHLiKGhve2BpdswLMEq1sEpxI2vI8MPYy2ts2iu40kcIc36822VxoSrBBq0U44 tgxZyaZ+MOMyeKEgJ80OOZmxTAFJ2DEPIYdz1RYmhDRhRAyCH4InHVv+fh5+axgwom2h GyBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735102588; x=1735707388; 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=QAZfSqVelueRAFHKq9hc0nxhbkTJuiO+q7f+eynL8Yc=; b=otIIwxstLSWCII3JkJeMbKMnXR1FDYkyDkt8VWxttkUv4uiyo1E1yj3YMomb3B2vwX C/GJg3CRzzaO0RwFvnBuvy4Dph4vlO/GCDk/F5PgmBHp4SnhMIFeum9fv+fQFf3XonWo Iw0nhiW75Y8TgwfAlN/aZSc3fvRkWic6akIey5QptLQhaP9pO9Xrr61ct+5jhSTRtK+Y kVvjDlPfM5468lQw/dLMm7zBrsHhAM3s1CTs7WKXEDmNTPDUfYvY9qpDBNPOPxSxDzAO rXSJHU/bfvhe7958bEJWdIXpqPRxyDHGUNlGPVjIreSymMNUENge0izSCXa6eivTk1z8 97Ng== X-Forwarded-Encrypted: i=1; AJvYcCWgR0T/1HIxuwmcKUm8a+wfxDl1MvhC/EPBjViNY9P6lqQgxHk2F6Uyt9eFKwWD4SvveJ/xIlIaVg==@gnu.org, AJvYcCWmm5iDE1aYe+stGOyTdi1d92gi0zbPzsPWBBRxhWZIoF7hhyz1WMhM+qLqhvj47NTUDPiD7eWWB6zoYfM=@gnu.org X-Gm-Message-State: AOJu0YzpUEoK4/A3ErqPG2T5jvv47H6LjwGahlHK3U05LBFPtvDwz1Rz iuwVOj3gyiZfwMrKYnqnXKSwbGiiML4P9ueN6zJlz20tqdMwTKf2kumOfg== X-Gm-Gg: ASbGnctBMEOP2GcrtdH0oBiqhe9wdRApSP3ra1eszwAWYAj9FvIIpP3TQ5r0iyYsqUj 7u86X6VnKPWEQDYPYNlyEKo586FnFic9KspYFz2EXMhRoJ1qj0fdAgqptzSSHYBLUvzU0/zmbgP 5z6MwQTdAariUFXDcDb9zlbO0P9FNzdg4D1G0vz450yy8aIVtOgwVNc+6gpVr2SngV/ztco4v8C POCoq/tMOuPKoLP1X6XNSR8HbafB6tRES3raxD+aDBd5zW8k49ux5aeMxh6dw+uQurJkDpKLUNu 2NrH3Hby23vU8b95DgMYqDH4WmHue70yRNJZxFd0T2bRk9O0GjHGsCnf7jqW X-Google-Smtp-Source: AGHT+IGYRx2jdgdlp98CHUSs5qomdG+/IyKXS3S4jG+0jfeFsqYxgdJfwos/riMpCUI6ACJJTLi1kg== X-Received: by 2002:a17:907:7da0:b0:aa6:af4b:7c90 with SMTP id a640c23a62f3a-aac3378bc11mr1969479266b.58.1735102588148; Tue, 24 Dec 2024 20:56:28 -0800 (PST) Original-Received: from pro2 (p200300e0b73d6f00401d1c7c2fc22e2d.dip0.t-ipconnect.de. [2003:e0:b73d:6f00:401d:1c7c:2fc2:2e2d]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0efe4b6bsm749871766b.93.2024.12.24.20.56.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Dec 2024 20:56:27 -0800 (PST) In-Reply-To: <861pxx2lh7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Dec 2024 16:40:04 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62b.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:327053 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, >> eller.helmut@gmail.com, acorallo@gnu.org >> Date: Tue, 24 Dec 2024 15:12:40 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > Now, with that definition, isn't specpdl stack part of "Lisp data"? >> > If so, and if we can safely access it from a signal handler, why do we >> > need to move it aside at all? And how would the "message handler" be >> > different in that aspect from a signal hanlder? >>=20 >> We're coming from the problem that MPS uses signals for memory barriers. >> On platforms !=3D macOS. And I am proposing a solution for that. >>=20 >> The SIGPROF handler does two things: (1) get the current backtrace, >> which does not trip on memory barriers, and (2) build a summary, i.e. >> count same backtraces using a hash table. (2) trips on memory barriers. > > Can you elaborate on (2) and why it trips? I guess I'm missing > something because I don't understand which code in record_backtrace > does trip on memory barriers and why. Ok, (2) begins as shown below. static void record_backtrace (struct profiler_log *plog, EMACS_INT count) { log_t *log =3D plog->log; get_backtrace (log->trace, log->depth); --- (2) begins after this line ------------------------------- EMACS_UINT hash =3D trace_hash (log->trace, log->depth); The SIGPROF can have interrupted Emacs at any point, both the MPS thread and all others. MPS may have been doing arbitrary stuff when interrupted, and Emacs threads too. Memory barriers may be on unpredictable segments of memory, as they usually are, as part of MPS' GC implementation. Do you agree with this picture? Elsewhere I tried to explain why I think this works up to the line marked (2) above. Now enter trace_hash. Current implementation: static EMACS_UINT trace_hash (Lisp_Object *trace, int depth) { EMACS_UINT hash =3D 0; for (int i =3D 0; i < depth; i++) { Lisp_Object f =3D trace[i]; EMACS_UINT hash1; #ifdef HAVE_MPS hash1 =3D (CLOSUREP (f) ? igc_hash (AREF (f, CLOSURE_CODE)) : igc_h= ash (f)); ^^^^^^^^ ^^^^^^^^ ^^^^ The constructs I marked with ^^^ all access the memory of F. F is a vectorlike, it's memory is managed by MPS in an MPS pool that uses memory barriers, so the memory of F can currently be behind a barrier. It doesn't have to, but it can. When we access F's memory and it is behind a barrier, the result is a nested SIgSEGV while handling SIGPROF. More code accessing memory that is potentially behind a barrier follows in record_backtrace.