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: Dynamic loading progress Date: Mon, 09 Mar 2015 21:26:57 -0400 Message-ID: References: <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.org> <54E382A5.5030408@dancol.org> <54F789B2.6030105@dancol.org> <54F9F066.6010902@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425950858 14284 80.91.229.3 (10 Mar 2015 01:27:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Mar 2015 01:27:38 +0000 (UTC) Cc: =?windows-1252?Q?Aur=E9lien?= Aptel , Eli Zaretskii , Stephen Leake , Emacs development discussions To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 10 02:27:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YV8xI-0000tK-SG for ged-emacs-devel@m.gmane.org; Tue, 10 Mar 2015 02:27:33 +0100 Original-Received: from localhost ([::1]:46038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8xH-0002ls-V0 for ged-emacs-devel@m.gmane.org; Mon, 09 Mar 2015 21:27:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8wu-0002kg-UB for emacs-devel@gnu.org; Mon, 09 Mar 2015 21:27:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YV8wq-0003yk-VJ for emacs-devel@gnu.org; Mon, 09 Mar 2015 21:27:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8wk-0003t6-SV; Mon, 09 Mar 2015 21:26:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJAPOG1lRLd/0j/2dsb2JhbABbgwaDX8Y4BAICgQ1EAQEBAQEBfIQNAQQBViMFCwsOJhIUGA0kiDgIziMBAQEBBgIBH494B4QqBalygUUihAoignMBAQE X-IPAS-Result: AlgJAPOG1lRLd/0j/2dsb2JhbABbgwaDX8Y4BAICgQ1EAQEBAQEBfIQNAQQBViMFCwsOJhIUGA0kiDgIziMBAQEBBgIBH494B4QqBalygUUihAoignMBAQE X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="113132282" Original-Received: from 75-119-253-35.dsl.teksavvy.com (HELO pastel.home) ([75.119.253.35]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2015 21:26:58 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F36CC1047; Mon, 9 Mar 2015 21:26:57 -0400 (EDT) In-Reply-To: <54F9F066.6010902@dancol.org> (Daniel Colascione's message of "Fri, 06 Mar 2015 10:22:30 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (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:183753 Archived-At: > Reasonable people can differ on the conservative scanning issue (JSC > does it; V8 and Java don't). If we bake the assumption of conservative > scanning into the interface, we're going to regret it later. Yes, if we define the API as using conservative stack scanning, then when we change to a GC that doesn't use conservative stack scanning, all the plugins will need to be changed correspondingly. Of course, when/if we make that change, we'll also have to make the same changes to Emacs's own code. My take on it is that making the changes to Emacs itself will be a crapload more painful than fixing the few affected plugins, so I'm really not worried about this eventuality. > I have to insist on not requiring staticpro, at least in its present > form. Registration of new GC roots (i.e., global references) must be > dynamic. Of course it should be. I didn't mean to take the current implementation of staticpro and expose it as is. Stefan