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 codegen Date: Thu, 13 Jun 2024 21:37:41 +0200 Message-ID: References: <87le3b43qi.fsf@gmail.com> <86r0d21tqj.fsf@gnu.org> <877cetgqiz.fsf_-_@gmail.com> <87wmmsg2e4.fsf@gmail.com> <87plskg035.fsf@gmail.com> <87ed90fyd3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10046"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 13 21:38:46 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 1sHqHW-0002Uz-9O for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Jun 2024 21:38:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHqGb-00018I-34; Thu, 13 Jun 2024 15:37:49 -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 1sHqGZ-000185-Sh for emacs-devel@gnu.org; Thu, 13 Jun 2024 15:37:47 -0400 Original-Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sHqGY-0003h3-5u; Thu, 13 Jun 2024 15:37:47 -0400 Original-Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57cad4475e0so3329055a12.1; Thu, 13 Jun 2024 12:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718307463; x=1718912263; 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=m7YcJP1M7tixkZD2HlROPAa/1L14yD6Y9ffNK0Tdhk0=; b=clNnlLjYSRtB6gcumMLKW9u4hBBlkC16B4v0auWAAH1V7OtislQhi8OB79p6KJ9a3O xbz8pIThyLXAUwwgHsMAopAyUmhbaPccTyZgEw5Za1mi8EauQXlzuwbLaB4Cx9k9guXq iBaJx4KX+72uTY+nDeZVtjdTbKaMje6z63xGz7Qf0nNkTcJntKVhxr+Kacsi1FHvYaQG zf1fNqA0fC+bFnKqjcKwiTS07AdXSYCAutJivEM+Pk1327tyliQNuDIDVIXpQ3Uho7LG Az87RW01Njp87n8uCNLZfB7mqGoFPmFswTIzTKYDEwQTwBZmWdwa95FFKyWPUTxlze3y 5DMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718307463; x=1718912263; 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=m7YcJP1M7tixkZD2HlROPAa/1L14yD6Y9ffNK0Tdhk0=; b=Vrv+bzSd7lvJvrG/VRa+PUHFoealgjfZU9jJXIA/mKWAPTG12dC6bfikAz1VeXhmmN FxKV51Z6aQ1O6C6g7R8S0M9dE9QOr09g1TQBPH2lhaIMqPzurpcGGB3GQ0zfr386EodC B/uwaHgmzkQJoPfKKuyr6KnlqWNw16/tsMxrqm4H2jRya9rcH/AuOKA+3cGjJTU1ZEwC 1YtvNW4GS3DmlFP4bWq6BnGGCai5zHqcf1+yFFQra+g9UqQiPkik52ibVu+0bp2xoNeH uzV9UxDwd7Y1bhNH9MGJy/ZUKFf2h3EkcmC+EfAqjA34r2iwur3+Z2YO9Mj6FB1qEH4U RjrQ== X-Forwarded-Encrypted: i=1; AJvYcCVfi0lePczpMYmQZ8ZEhnt3fTcooWIl0OElIBMVIkcuFZorx6PvVpVp2srWGVqIfJS4G9v2GnvmSru8P2cQ5CtvXnRM X-Gm-Message-State: AOJu0YyQyzV5CWmEq2twiHTIJcjOAzeLdVcXMpp8NHH0oBBsUv3Ps642 EdEAc3WisdNMbyk2PsMMcqpCdbJ25qdXQNNn+kJ3E52vwV6cB0FHfy9Kmg== X-Google-Smtp-Source: AGHT+IHtxKpWLXMDmX701gBa3CFS8ew+0ki8OV9ehCynPu5vM3kLoTgC2g1ln1Sw7drUsYq1HZyMNQ== X-Received: by 2002:a50:ab54:0:b0:57c:7f3a:6c81 with SMTP id 4fb4d7f45d1cf-57cbd69eb68mr534550a12.8.1718307462610; Thu, 13 Jun 2024 12:37:42 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3aa9f.dip0.t-ipconnect.de. [79.227.170.159]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57cb741e7a5sm1267119a12.75.2024.06.13.12.37.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 12:37:42 -0700 (PDT) In-Reply-To: <87ed90fyd3.fsf@gmail.com> (Helmut Eller's message of "Thu, 13 Jun 2024 21:15:20 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x532.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:320038 Archived-At: Helmut Eller writes: >>> The win would be that no code for copying and mirroring would be needed. >>> One downside would be that the hot and cold section end up in the same >>> pool. >> >> Then I didn't understand what you meant. How would you avoid the >> copying? I don't remember seeing something in the MPS docs by which one >> could let it manage a area of memory the user can allocate or specify. > > The idea is simply to do something like dump_mmap_contiguous_heap. > Instead of malloc'ing the contiguous chunk of memory use mps_reserve. > After the pdumper has done the usual relocations call mps_commit. Ah, that's an intersting idea! > (It might not work out quite like this because the pdumper wants to > allocate something too early, ie. before the mps_commit. But that's the > basic idea.) Maybe one could reserve + commit a suitable block upfront, maybe as one big IGC_OBJ_PAD, and use read(2) or so to read the .pdmp into that block. One problem would be to make the whole thing digestable for the object format. And maybe one would loose the ability to use the leaf pool for some objects in the dump. But maybe that's not a big deal. MPS then calls the scan method which does nothing, but that should be the whole overhead, I guess. If one could get rid of the mirroring code, that would be a big advantage :-)! > The crucial bit that I'm unsure about is if mps_reserve can be used to > allocate many objects in this way. I think it can. But the proof is in the pudding, of course :-).