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: [Emacs-diffs] trunk r113437: New unwind-protect flavors to better type-check C callbacks. Date: Tue, 23 Jul 2013 09:21:48 -0400 Message-ID: References: <51EE4645.4000904@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374586165 27115 80.91.229.3 (23 Jul 2013 13:29:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2013 13:29:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 23 15:29:26 2013 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 1V1cec-0000EH-8Y for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2013 15:29:26 +0200 Original-Received: from localhost ([::1]:49383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1ceb-0004qm-SQ for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2013 09:29:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1ceE-0004Iq-M9 for emacs-devel@gnu.org; Tue, 23 Jul 2013 09:29:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1cXG-0006EW-3X for emacs-devel@gnu.org; Tue, 23 Jul 2013 09:22:14 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:33902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cXF-0006EH-Ur for emacs-devel@gnu.org; Tue, 23 Jul 2013 09:21:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsoXa8/2dsb2JhbABEDr8AF3OCHgEBBAFWIwULCzQSFBgNJIgeBrEfkA6RCgOkeoFegjla X-IPAS-Result: Av4EABK/CFFsoXa8/2dsb2JhbABEDr8AF3OCHgEBBAFWIwULCzQSFBgNJIgeBrEfkA6RCgOkeoFegjla X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="19602551" Original-Received: from 108-161-118-188.dsl.teksavvy.com (HELO pastel.home) ([108.161.118.188]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jul 2013 09:21:42 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9E84C62DB7; Tue, 23 Jul 2013 09:21:48 -0400 (EDT) In-Reply-To: <51EE4645.4000904@cs.ucla.edu> (Paul Eggert's message of "Tue, 23 Jul 2013 10:00:53 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162090 Archived-At: > To avoid the problem, there needs to be a way to > invoke record_unwind_protect without the possibility of > throwing an error before the protection is in place. Why? > It wouldn't be feasible to convert all uses of > record_unwind_protect to record_unwind_protect_ptr, because > not every function that calls record_unbind_protect also > calls unbind_to. Oh, man, that's even worse than I thought. This is really bad, it means that it suffers from the same kind of limitations as alloca, i.e. it is tricky to use and coders need to be extra aware of it (e.g. common code refactoring can be unsafe). > Removing record_unwind_protect_int would not be trivial, > since one can't simply replace it with record_unwind_protect > + make_integer (as not all 'int' values fit into Lisp We've lived with it for what... almost 30 years? > This would slow down execution very slightly, though. As mentioned, the extra cases in unbind_to also cause a minor slowdown, so I don't think this is a significant argument. >> No strong technical arguments for it (other than the fact that the >> added SPECPDL_UNWIND_* cases in the switch slow down `unbind'). > It shouldn't slow down 'unbind', at least on my x86-64 > platform, since the switch is implemented as an indirect > jump, which means that adding cases doesn't add any > instructions for the existing cases. The problem is not the number of instructions but the time taken by each instruction because correctly predicting indirect jumps is very expensive and adding cases to the switch will increase the number of mispredictions. Stefan