From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: New GC concept Date: Fri, 4 Jun 2021 13:06:11 +0200 Message-ID: <6f7607ad-6841-650b-a165-1e04f974eadf@daniel-mendler.de> References: <1658db95-d513-7f21-8751-0e2ea38946cb@daniel-mendler.de> <06073468-e016-52af-9a84-99ef4cf00d78@dancol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25138"; mail-complaints-to="usenet@ciao.gmane.io" To: Daniel Colascione , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 13:07:20 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 1lp7fb-0006Ql-HB for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 13:07:19 +0200 Original-Received: from localhost ([::1]:43248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp7fa-00015Q-KC for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 07:07:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp7eh-0000Ae-Jl for emacs-devel@gnu.org; Fri, 04 Jun 2021 07:06:23 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:42431 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp7ed-0008Sx-LL for emacs-devel@gnu.org; Fri, 04 Jun 2021 07:06:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0QeOFMAjie1tXOBmJBcOn1xV+txJdG1+NiTlWSAtdjU=; b=KcEqu1bYlybXcWGx+5JxRTxfLY apFmruZl3iojPjUnBxOSAFAnpkqIAgXV1+f3fww7Zi/edwJmbilRG/MqBPccDEOvnZtryjQU+UIMb jRum4zUKgDCRMnjVHBasBy016F0B9Fhhc/e5rdbN8NNvAo+UO2lF6GFsnum03Zcz6d5w=; In-Reply-To: <06073468-e016-52af-9a84-99ef4cf00d78@dancol.org> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:270380 Archived-At: Thank you for answering my questions. Did you also consider the approach of using a non-copying collector, keeping the classical mark and sweep? Andrea mentioned in his mail that the focus should be on reactivity. With mark and sweep it is possible to avoid the copying step, which scales with the live size, such that one can achieve constant pause times. On the other hand the copying step is probably quick for the expected Emacs heap sizes. Furthermore with m&s, you have the fragmentation problem, it is harder to use such a bump-style allocator and it is harder to separate the generations, which is a requirement for the hardware write barrier. So I think overall your design is a sound approach as long as the heap stays at a reasonable size. Your approach seems to be quite general purpose and does not require intrusive changes to the Emacs C code; it seems to be relatively decoupled from the Elisp runtime. Do you think it is realistic to implement the GC as a "library" behind some abstract interface? Of course there is some dependence on the object memory layout, but the GC interface could offer APIs to request objects of different types. It should then be possible to use different GCs which use a similar approach (conservative stack scanning, no explicit read/write barriers). Daniel Mendler