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 signals and Emacs Date: Mon, 22 Apr 2024 12:22:25 +0200 Message-ID: References: <878r16n5jl.fsf@gmail.com> <87ttjulb16.fsf@gmail.com> <86a5ll7wj9.fsf@gnu.org> <71431fc4-2ab2-4778-88df-25d4e315d737@cs.ucla.edu> <00fec231-a625-406e-a51b-cb66710c6482@cs.ucla.edu> <86wmop6cot.fsf@gnu.org> <86v8496ajl.fsf@gnu.org> <86ttjt69i2.fsf@gnu.org> <86sezd68g8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eggert@cs.ucla.edu, eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 22 12:23:23 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 1ryqpX-0002hF-Da for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Apr 2024 12:23:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryqol-00040e-Ng; Mon, 22 Apr 2024 06:22:35 -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 1ryqoj-00040H-Ey for emacs-devel@gnu.org; Mon, 22 Apr 2024 06:22:33 -0400 Original-Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ryqof-0002wr-Qq; Mon, 22 Apr 2024 06:22:32 -0400 Original-Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so8976179a12.1; Mon, 22 Apr 2024 03:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713781347; x=1714386147; 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=sw6o0qP7QwTwRP8GtFpdJqTiQOLlMIqWRcKh5nEyhsc=; b=db8OgOJcNs+o1YKWII6K1jY8OeC2NK7ePgqxbhefM0xZjUGjVITYNb22xrBxli8vEM tWRZuTKc3M2vEiUEYXpetW5tUQcCXT+AANFATbvWjgMsXW6cOOhw4gy7pE6IySwzMwGt LlJ41lorbqAiBNMCDUt/b0nHy1y0n1ps4W1zU0yPQ4YXdUOxv5YsVu9qPrnJ2rCGO3zP 8fv7+plLjh1avpUuZlloZvOYsLerA4A3Y/bC1cD/zwnB2UpYVqtrQc3zytIzwyeSgQMg Uw2QdJn/0r/a4HJzhQY3LkpAaZIZNEhDVdn+tg5N7Jy8gFhmrhf7bZuTXYWcVyeH6Czx aDoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713781347; x=1714386147; 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=sw6o0qP7QwTwRP8GtFpdJqTiQOLlMIqWRcKh5nEyhsc=; b=Kv4caYGGb/voKkQVNojr1ryVdnTZbAWNEFAbdZv7EhOwhQa2Kmo68Ahkif8thEnXRN kORxFwYBwoprJQoxes3wAkrNMZqQ+OYo2rf50vkB4vTS81zXGThLG5e4j7+b/D0kMA3a mBtCiY3IQZ2Rk9SG4eJCWa9oqfNCxZAHRLW1Sj6ZmIrqLxuuhGwSOdmu2m2udurBL/gu BvTd2laZ3p3HLxzP/uUSku++3BDwEf/M3zRu1CeoGjPLWGREMZvfUMO667QVGU+EGspV MMIhWvcIp/eD1czvqL8UBYvKZq3eRET10+grRXwscHujwQQahpzvW/L9c+ip+ghzVQ2q DOeg== X-Forwarded-Encrypted: i=1; AJvYcCUAuYk4iMv/0OMbFOvYIwxapr2ED+2zxGGJb+mj/jpL+F26oqPTgM139NZBkvf97ew/H8Ogo6KMq3EpqRcSVrbZCQW4 X-Gm-Message-State: AOJu0YywEcO2BethFrvW6Bdwts9ADNCkxIymFCwvEroGBIJdPW6tQzaw 7qbUQR8wXiynPuRYr8ibDZjhkDfa3dbpkBUnBwoWz9sctnnD5S2mGj4vyw== X-Google-Smtp-Source: AGHT+IHAja87dMpwaJLnncPkV8ZDIAuFdEJQBcfsqwZ8s6139iNwsWpOE3qz+2AW0GTsMNLRW/75PQ== X-Received: by 2002:a17:907:2684:b0:a55:7669:8b4a with SMTP id bn4-20020a170907268400b00a5576698b4amr12633441ejc.32.1713781346682; Mon, 22 Apr 2024 03:22:26 -0700 (PDT) Original-Received: from Pro.fritz.box (p4fe3af79.dip0.t-ipconnect.de. [79.227.175.121]) by smtp.gmail.com with ESMTPSA id qy34-20020a17090768a200b00a55a59c629fsm2109150ejc.121.2024.04.22.03.22.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Apr 2024 03:22:26 -0700 (PDT) In-Reply-To: <86sezd68g8.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 22 Apr 2024 12:41:11 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52a.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:317971 Archived-At: Eli Zaretskii writes: > Doesn't copying GC work by copying live objects to a new memory > region, and then freeing the old region? If so, if some objects > cannot be moved, how can the old region be freed? Yes. A simple precise GC (no support for ambiguous references) might work with 2 regions, which are usually called to-space and froms-space. When a GC happens, everything live is copied from from-space to to-space. At the end, to-space has all live objects, and both spaces can switch roles in the next GC. That doesn't work with ambigupus references, of course. Instead imagine a memory area that is divided into a number of subregions, let's say into VM pages, I think that's a good example. Add to that some administrative data structures holding information about pages, say if it's part of to-space or from-space. Just as an example, there are so many variations, of this... Now a GC happens. We can copy objects from a pages in from-space to a page in to-soace, and everything works as in the copying collector, in principle. At the end, we just switch what we consider to-space and from-space. Maybe a 1 in the page info data structure formerly stood for to-space and 0 for to-space. Now exchange the meaning of 0 and 1. Ok, I hope. Now say we have an ambiguous reference to an object O in page P. We can copy the objects as above, but not O, which we leave where it is. At the end of the GC, we move P to to-space by simply changing its number in the page info data. Mission accomplished. Hm, I have to add that this is such a drastically oversimplifying horrible description that I slmost get a bad conscience. Almost ;-).