From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Finding objects on C stack - alternate GCPRO Date: Wed, 16 Nov 2011 09:41:36 -0500 Message-ID: References: <4EC38B72.1000101@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321454517 26600 80.91.229.12 (16 Nov 2011 14:41:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2011 14:41:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 16 15:41:50 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RQggP-0002Uc-Eu for ged-emacs-devel@m.gmane.org; Wed, 16 Nov 2011 15:41:49 +0100 Original-Received: from localhost ([::1]:42727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQggO-0001dz-KG for ged-emacs-devel@m.gmane.org; Wed, 16 Nov 2011 09:41:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:46956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQggJ-0001bs-3j for emacs-devel@gnu.org; Wed, 16 Nov 2011 09:41:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQggE-00023e-J3 for emacs-devel@gnu.org; Wed, 16 Nov 2011 09:41:43 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:2911 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQggE-00023S-GT for emacs-devel@gnu.org; Wed, 16 Nov 2011 09:41:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADXLw05MCqs//2dsb2JhbABDqXaBBoFyAQEEAVYWCgMFCwsOJhIUGA0kiBW5HIoXBIgUmXCESg X-IronPort-AV: E=Sophos;i="4.69,521,1315195200"; d="scan'208";a="148208264" Original-Received: from 76-10-171-63.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.63]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2011 09:41:37 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A16875936A; Wed, 16 Nov 2011 09:41:36 -0500 (EST) In-Reply-To: <4EC38B72.1000101@yandex.ru> (Dmitry Antipov's message of "Wed, 16 Nov 2011 14:07:46 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146059 Archived-At: > Everyone agrees that GGPROs are ugly and painful. On the other side, > current C stack marking code introduces substantial overhead by > maintaining red-black tree. I don't think the red-black-tree is a big overhead, in general. The only place where it is significant is when (de)allocating small vectors, which we could solve by using a special allocator for small vectors. > And, since C stack marking is conservative, it becomes very tricky to > implement GC that may relocate live objects (copying or compacting > approach). Making all objects relocatable would require not only "precise marking" but also "exhaustive marking" which is currently not the case. Given the bugs we bump into already for string relocation I'd expect that making all objects relocatable would make for a lot of nasty debugging unless we can get GC info to be exhaustive (including C pointers into Elisp objects) in a fully automated way (i.e. without any manual annotation, be it GCPRO or FOOPTR). > But there is another method to implement GCPROs. It looks not very > portable beyond GNU C since it uses __attribute__ ((cleanup (function))) > and compound statement expressions C extensions. But it doesn't > require UNGCPRO and dumbs like 'struct gcpro gcpro1, struct gcpro2, ...'. > And I believe it should work across longjmps. Interesting. You'd need to adjust your macro so as to make sure that the Lisp_Object variables are initialized before they're added to the gcpro list, but otherwise it's indeed cleaner than our current macros. On the performance side, it could be slower depending on how aggressively gcc optimizes alloca and foo_remove calls and more importantly depending on whether it handles longjmp for us (which would be less efficient, tho I don't know if that would be significant). > This idea is briefly illustrated by an attached example. As for the > Emacs, it would be enough to declare every local Lisp_Object which > should survive the GC with the stuff like FOOPTR from this example, > and we're ready for exact C stack marking with (hopefully) very small > overhead. The problem is that the few platforms that don't use GCC are the ones that require GCPROs as well, so not only it would be a large change, but it would also require us dropping support for those non-gcc non-conservative-GC platforms. I guess this would only make sense if we decide to use this FOOPTR in preference to conservative stack scanning. But as it stands, I don't see it happening, unless we have some compelling reason to do it (e.g. benchmark showing there's a significant gain, or actual new feature/code to take advantage of the extra gcpro info). Stefan