From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: New GC concept Date: Thu, 3 Jun 2021 20:30:26 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2421"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 05:32:36 2021 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 1lp0ZX-0000Ti-Pp for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 05:32:36 +0200 Original-Received: from localhost ([::1]:45426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp0ZW-0006RX-O5 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Jun 2021 23:32:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp0XX-0005aN-HP for emacs-devel@gnu.org; Thu, 03 Jun 2021 23:30:31 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:38948) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp0XV-0005au-1V for emacs-devel@gnu.org; Thu, 03 Jun 2021 23:30:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=MpXFBk0uY+8mXWY9vqPxmQ9BwpMbSpNS9ruvgBEOvBg=; b=W 0wlxQ6bcTUjJrY894vUTMEzjcMtUpEIf4yABb7tNG7cXl3NT87Ddp9RjEe9GMsah2e4IY2he263hb S3fNnIH0QK14P0D91qvYC8zaf1yUm0giOv3qWV6FMUJF0/a0FI0DpnZUaPuY94UpldBlzRo+1dhkn MEcYLeLwRqh8DRM4cXZkIEHDoJcBwiiCXj8C266JWuckocaNO95BOQPW37xqCasLPjvHi0kMzYTVi 3cprOb0N22GcCz5Lh+GZl8jMWr79NgQRZ+Zx9OCWJsDsuOmupTw7ERM0Fo19EnVyEoXHKvo9euffC mRm0Uzf4cfOr1jNSwd6rOjolkPcijVfzg==; Original-Received: from [2604:4080:1321:8020:2761:c5fe:e373:3ed] (port=41372) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lp0XS-0008J1-RC for emacs-devel@gnu.org; Thu, 03 Jun 2021 20:30:26 -0700 Content-Language: en-US Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org 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, SPF_HELO_PASS=-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.23 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" Xref: news.gmane.io gmane.emacs.devel:270360 Archived-At: Emacs has had the same GC for a decent amount of time now (since the 1980s, really). I spent some time in 2020 rewriting it from scratch. I haven't had time to work on the new GC recently, but I figure I'd throw it out here to get some feedback on the general concept. Check out https://github.com/dcolascione/emacs-1/blob/newgc-wip/src/alloc.c, specifically the big doc comment on top The new GC basically replaces alloc.c and a few other things. It has a few cool features: * fully copying and compacting * special treatment of sxhash to preserve object identify even while we move it around in memory * generational * contiguous storage of mark bits separately from the data heap * concurrent (in design, not current implementation): idea is that we do concurrent marking and barely pause for sweep * small string optimization * bump pointer allocation of new objects * heap enumeration support * hard requirement on pdumper * specialized GC spaces for conses, strings, arrays, and so on: no stupid header word for cons cells bloating memory use by 50%! * cool modern C implementation that relies heavily on compiler inlining and constant propagation The current implementation is deficient in many ways. Honestly, I'm not even sure whether that specific revision compiles. But like I said, I haven't had time recently to continue work on it. Still, I'm still curious about what people think of the overall effort. It might work nicely with the new native compilation stuff, giving us a managed code execution environment kind-of, sort-of on par with the big modern managed-code runtimes.