From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Geza Herman Newsgroups: gmane.emacs.bugs Subject: bug#74547: 31.0.50; igc: assertion failed in buffer.c Date: Sun, 1 Dec 2024 17:32:21 +0100 Message-ID: <11705193-9151-43fb-9109-8a579e77d32b@gmail.com> References: <87serdu9m3.fsf@telefonica.net> <875xo3mvqh.fsf@protonmail.com> <871pyrmui4.fsf@protonmail.com> <87wmgjlabu.fsf@protonmail.com> <87r06rl807.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------Yd0QfrXRzY0YtXSFwv4UVQBF" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8622"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 74547@debbugs.gnu.org, =?UTF-8?Q?=C3=93scar?= Fuentes To: Pip Cet , Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 01 17:34:24 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tHmts-00025u-JH for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Dec 2024 17:34:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHmtc-0006M3-36; Sun, 01 Dec 2024 11:34:08 -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 1tHmtW-0006KB-SO for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 11:34:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tHmtW-0008DG-JS for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 11:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=qR+izncIY56V0NZ6aug0fSMp89RWJrhIoFykmXsHjtI=; b=kjjh/fbspa9WObGjAR/4Rsx1UpvoD25VM/7wVd9aXUSesxaCDI96wZgwgGw0OsZ+RKooI/SKJHGiAZPumV8mYzJXlAdWb1T/lvFzPwBCqJTqTKWmT1kxHBYj4amLqth4+o9jbwSFRMAvZjwDIeSWWL13P6uJdbSmBsK7G1l0NiFnj8pufQRDYZM4nB+jih8zYIpcLB5Wo5uRy0Clx4nh/hqeyLVoxcmWkcGVkk/gwMRbl9OPpUcLk37HEnWHoyaly4z+ZE6sXdrrMDqV2JKxoI0znBOXJXOu9sdr7tCcv+q4E96/0YNgUlHw8Z0lAt7Z2e3I335xPHbYKxXbQUdZLw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tHmtW-0002x9-E2 for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2024 11:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Geza Herman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Dec 2024 16:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74547 X-GNU-PR-Package: emacs Original-Received: via spool by 74547-submit@debbugs.gnu.org id=B74547.173307080811291 (code B ref 74547); Sun, 01 Dec 2024 16:34:02 +0000 Original-Received: (at 74547) by debbugs.gnu.org; 1 Dec 2024 16:33:28 +0000 Original-Received: from localhost ([127.0.0.1]:52849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmsy-0002w3-1k for submit@debbugs.gnu.org; Sun, 01 Dec 2024 11:33:28 -0500 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:51206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHmsu-0002vq-U1 for 74547@debbugs.gnu.org; Sun, 01 Dec 2024 11:33:26 -0500 Original-Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-385e0e224cbso1130113f8f.2 for <74547@debbugs.gnu.org>; Sun, 01 Dec 2024 08:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733070744; x=1733675544; darn=debbugs.gnu.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qR+izncIY56V0NZ6aug0fSMp89RWJrhIoFykmXsHjtI=; b=lYF4PAlV5p1+agP2wJ752+Nf6VxeqFp0HPLO48ETLh64O236O5PIknmKwsg73VEBEI k1GfNY74pwbcL5rlXxzGh0AE1o80mTFgbTquZVNMHFgexqrJEmnsjUVJyOQxUBGwuhys DtwgwwrMkJrXoT3vg+eEx62Pf0ROcS7ww3mShoi14hkBLLj0Q8/gue6+Ul2GOVjwHHcL bbxqRoiYmLTsGmv+I9mQhACeNU+o44iIYEBjUsUY3juJN6HEPkDCqVxyfd7yPDsDXYMa GljxnvTFK4QBgM3ns+SI4Nqy90cgcXIf3XnyhbHZIcbMQnQWmdOcNiIVb4b+5sX2SAGb 7biA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733070744; x=1733675544; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qR+izncIY56V0NZ6aug0fSMp89RWJrhIoFykmXsHjtI=; b=C9mv0pmUNzNCejseDpLmv7zI/suJsr+bxEv2rL2xWEi2BUVoDq/EWTJzYGnzjlMb8S MnyKNUr9ylrm9gifv50FAl3vgBEtp9HTRIJ8ziwuzX7z8Z15s3g+cORnpQ2WFuDk85rL lom57F3NeEhvAwF1ggn+QSAdp2aM+CdFJz4DLDTAeS6h+hUFWEcqrU8kBG9nxE2j5g75 40iCfWR5ee1/5U2xjHJ8UKJnu75AEk+uFsYZtJ5W2/NKgUAhaddZtOtBCyonOyFIiNuW Z8cmLQoACYlbrRBBdrry8uX+Zi9tfAhjkvNCZNp9n6CViZOfO6TMd61YHPiNY3foHagA GdAQ== X-Gm-Message-State: AOJu0Ywjt0i1xE86LkBfGHZAxDR8nw1laFsYtlnxKP7Dn9S9jDggTjIM s04xjWsBSVXiyjN1UclG7gCvD0lDfz9u612RPs/3aZ7YMIksD3k6 X-Gm-Gg: ASbGnctQLoeqWGKhKzYnNOXE/hjEg/v20jocofKGJWNNOxJt38jxKPy3Ly1zESqb1XN 2U/p2CGhbOVf3L2l8VKnupCOZuadfQeGcbpCXl0+elZkkV3CQLr616RZU4lAx4Q30vueuiKuE9h JHG+L41jcbou0fVdY6hIx2GRzWahCkUmWMxgFmoBblQnSB1VayBcTk+rJI+WEsFjKuWA6Iqcqy5 f3akZ50RYH39BCrklDUxPDKC/ebqJ5qsakU64GI2Ngc2H/y1i8Rm0uQMi0r7yOuO1njGroCpfHZ aJS4AINu X-Google-Smtp-Source: AGHT+IFF6ck/bex1q5S44mMkjJLj5jLNpO7dT3Kp9TkBoZlaaabVZRDGTSEWguPpCmFEC9Ep3cp1KQ== X-Received: by 2002:a05:6000:1fa3:b0:385:eed9:cbca with SMTP id ffacd0b85a97d-385eed9cda6mr1822412f8f.27.1733070743708; Sun, 01 Dec 2024 08:32:23 -0800 (PST) Original-Received: from [192.168.1.65] (1F2EF6E9.nat.pool.telekom.hu. [31.46.246.233]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa7e5285sm152947865e9.40.2024.12.01.08.32.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Dec 2024 08:32:23 -0800 (PST) Content-Language: en-US In-Reply-To: <87r06rl807.fsf@protonmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296266 Archived-At: This is a multi-part message in MIME format. --------------Yd0QfrXRzY0YtXSFwv4UVQBF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/1/24 16:48, Pip Cet wrote: > Gerd Möllmann writes: > >> Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented >> at some point, but removed again, see >> >> https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/ >> >> I vaguely remember a longer thread about GC in json.c at the time. Could >> be that that was before igc became a realistic possibility, don't >> remember. > Okay, sounds like it's a political issue. I'll push the first patch > which keeps changes to a minimum. > > Pip > Back then, the future of the new GC was a question, so Gerd said (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that "Please don't take my GC efforts into consideration. That may succeed or not. But this is also a matter of good design, using the stack, (which BTW pdumper does, too), vs. bad design." That's why we went with the fastest implementation that doesn't use lisp vectors for storage. But we suspected that this JSON parser design will likely cause a problem with the new GC. So I think even if it turned out that the current problem was not caused by the parser, I still think that there should be something done about this JSON parser design to eliminate this potential problem. The lisp vector based approach was reverted because it added an extra pressure to the GC. For large JSON messages, it doesn't matter too much, but when the JSON is small, the extra GC time made the parser measurably slower. But, as far as I remember, that version hadn't have the small internal storage optimization yet. If we convert back to the vector based approach, the extra GC pressure will be smaller (compared to the original vector based approach without the internal storage), as for smaller sizes the vector won't be actually used. Géza --------------Yd0QfrXRzY0YtXSFwv4UVQBF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/1/24 16:48, Pip Cet wrote:
Gerd Möllmann <gerd.moellmann@gmail.com> writes:


Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented
at some point, but removed again, see

  https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/

I vaguely remember a longer thread about GC in json.c at the time. Could
be that that was before igc became a realistic possibility, don't
remember.

Okay, sounds like it's a political issue. I'll push the first patch
which keeps changes to a minimum.

Pip

Back then, the future of the new GC was a question, so Gerd said (https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that
"Please don't take my GC efforts into consideration. That may succeed or not. But this is also a matter of good design, using the stack, (which BTW pdumper does, too), vs. bad design." That's why we went with the fastest implementation that doesn't use lisp vectors for storage. But we suspected that this JSON parser design will likely cause a problem with the new GC. So I think even if it turned out that the current problem was not caused by the parser, I still think that there should be something done about this JSON parser design to eliminate this potential problem. The lisp vector based approach was reverted because it added an extra pressure to the GC. For large JSON messages, it doesn't matter too much, but when the JSON is small, the extra GC time made the parser measurably slower. But, as far as I remember, that version hadn't have the small internal storage optimization yet. If we convert back to the vector based approach, the extra GC pressure will be smaller (compared to the original vector based approach without the internal storage), as for smaller sizes the vector won't be actually used.

Géza
--------------Yd0QfrXRzY0YtXSFwv4UVQBF--