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: a random backtrace while toying with gdb Date: Mon, 01 Jul 2024 20:19:09 +0200 Message-ID: References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86tthafbix.fsf@gnu.org> <87plry6sv3.fsf@localhost> <86le2lfjqv.fsf@gnu.org> <87jzi5ibbe.fsf@localhost> <864j99fg0a.fsf@gnu.org> <87msn18225.fsf@localhost> <86le2ldn2t.fsf@gnu.org> <87h6d97zzm.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12725"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , eller.helmut@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 20:19:48 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 1sOLcw-000359-Ex for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 20:19:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOLca-0003zX-G6; Mon, 01 Jul 2024 14:19:24 -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 1sOLcY-0003z8-Qt for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:19:22 -0400 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOLcQ-00005K-GT; Mon, 01 Jul 2024 14:19:22 -0400 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-57ccd1111b0so410184a12.3; Mon, 01 Jul 2024 11:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719857951; x=1720462751; darn=gnu.org; h=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=BDSIWgLpr4Xzi9iQCrfVgWCc1JURRckz5LnPbkUBpak=; b=gA0luj4m7KGiTmxIeM8DaoZao40nbLGNdoT+dFct6ZD+9dg9QGR1nD0cJSewc8clZf hCVOYY6ugDymnhnuBHn/HCRfBvLNopa05wv4DUt5L0A3ptztYOOuT/pn7ZBSpBMNfuj9 K/kPvvRSw6XZiBZHDBuSMrZh4ZoqmAQG6h7n7OSBOtyXklBsuB7qxEggqXjkwYFVwCXh IstHqER5x7GTQTD9PspMaKzfn5EiKi5qn5APgYmjvA9fgCwOskvLIiaA49sgM3u+d09u xrVDA/Eqjhw/yAF5vv9Laf3FUaNeuNRbodKgsbFbd8PUtfane3Ak3+0eOz9SBIcopvfX 93HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719857951; x=1720462751; h=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=BDSIWgLpr4Xzi9iQCrfVgWCc1JURRckz5LnPbkUBpak=; b=WdI55+417MSzQ6r16d9rkPeVCT/wUSNipcJxY2WoHnG9S8lEiDZphR78+kfZ4J4qzR a0tU/zA2NG33kZTdx3niId+HeV4iKAUm3rJN2xp1IiogaU7EtyuA7ABGnKacwQv0oiOT RcCP1F4FvI8D3r6uYj8qRH6LOIZZOhw/g2jE3Ia4hkWa3V79bnOPqTUYy/mRJ2qSMtXM reWyVQBqOlVFuyThbqSSxTQP0vZttdbC7/kh8ORP60VtMcqiUUz5aFEiguUCl07LyFUB UAuoXB7IVV+BgCpG/uu5jAhXuGogqlnA3nxvDjtQuRZF6DOQE+YqukZOIDJuVwqK9GYv ZXww== X-Forwarded-Encrypted: i=1; AJvYcCVv6Oxw5v3arcqvoC+UhLwmrexKTTSU+0cd2i9908kgJPTSHYhm48ri5AxW2QXTJM6G0YT9y8SdnVI/3/o0doRjOOrG X-Gm-Message-State: AOJu0YzuWoNXjMRD0p+GZ8jTzZQYSo7DLgoYlL/26F7WZRmmHwUu3ymO uOhdIPprQa9mQ3rxgo9CAUJj5pdP67aAIUQKKoVUnlSJnVbVs7HJyhhM9w== X-Google-Smtp-Source: AGHT+IEfUKIAafGmX3/fvxnQaRr1LGp42ZCkjVUnsLvii71+aep2bU/XmNVCPIy6tcQbb7lxXhMLNg== X-Received: by 2002:a05:6402:5194:b0:57a:3046:1cd8 with SMTP id 4fb4d7f45d1cf-5879ede276emr5439374a12.7.1719857950806; Mon, 01 Jul 2024 11:19:10 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a7fc.dip0.t-ipconnect.de. [79.227.167.252]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5861503b4c5sm4622989a12.93.2024.07.01.11.19.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 11:19:10 -0700 (PDT) In-Reply-To: <87h6d97zzm.fsf@localhost> (Ihor Radchenko's message of "Mon, 01 Jul 2024 18:01:49 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52b.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, T_SPF_TEMPERROR=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:321049 Archived-At: Ihor Radchenko writes: > Eli Zaretskii writes: > >>> I am wondering what happens in the same situation when using normal >>> malloc. (Or may it never happen when using normal malloc?) >> >> You mean, when the current GC runs? > > Nope. AFAIU, the problem we are facing is not when MPS GC runs, but when > we query MPS to allocate memory in the managed arena. AFAIU, there are 2 scenarios: 1. The client allocates memory from MPS, via an allocation point. APs normally allocate from a block they reserve, which is why this is usually surprisingly fast. More must done when the reserved block is used up. Then, MPS scans mempory, tries to free some, and so on. This happens synchronously in the client thread. 2. MPS concurrently does incrementally work. It scans some part of the meoory, for example, and functions of the object format are called (those in igc.c). This happens in the MPS thread. >> If you really mean malloc, then there usually is not problem because >> signal handlers cannot safely call malloc. And if malloc causes GC, >> see above. > > I do not mean calling malloc. I mean, what happens if a signal arrives > _while_ malloc is still in the process of allocating data? One would have to consult the malloc implementation. Portably, it's not safe to call malloc in a signal handler.