From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [RFC] temporary Lisp_Strings Date: Tue, 02 Sep 2014 07:37:18 -0700 Organization: UCLA Computer Science Department Message-ID: <5405D61E.8090604@cs.ucla.edu> References: <5405BE5D.1090003@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1409668689 13698 80.91.229.3 (2 Sep 2014 14:38:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Sep 2014 14:38:09 +0000 (UTC) To: Dmitry Antipov , Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 02 16:37:59 2014 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 1XOpDa-0003h1-Hp for ged-emacs-devel@m.gmane.org; Tue, 02 Sep 2014 16:37:58 +0200 Original-Received: from localhost ([::1]:38509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpDa-00060m-4q for ged-emacs-devel@m.gmane.org; Tue, 02 Sep 2014 10:37:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpDQ-00060c-3z for emacs-devel@gnu.org; Tue, 02 Sep 2014 10:37:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOpDI-0007w7-JY for emacs-devel@gnu.org; Tue, 02 Sep 2014 10:37:48 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOpDI-0007ul-EA for emacs-devel@gnu.org; Tue, 02 Sep 2014 10:37:40 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A6C70A60012; Tue, 2 Sep 2014 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB59v-4fDwoq; Tue, 2 Sep 2014 07:37:23 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 094F7A60006; Tue, 2 Sep 2014 07:37:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <5405BE5D.1090003@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:173952 Archived-At: What would the GC do when it sees such a string? Wouldn't this make the GC a bit less robust, as it couldn't diagnose bogus strings any more when GC_CHECK_MARKED_OBJECTS is defined? Like Stefan, I wonder how much performance benefit you're really gaining here. Presumably most of it is lack of pressure on the GC, and how do you measure that? I assume you're thinking of eventually doing this for conses etc. too? Dmitry Antipov wrote: > is there a way to make sure that an address returned by alloca fits in Lisp_Object? It should work on typical platforms, as alloca should return an address that is aligned well enough for Emacs, just as malloc does. Perhaps we may run into an oddball platform where alloca isn't suitably aligned, but if so we can simply allocate a few more bytes than needed and then align the pointers ourselves. For starters, though, I'd just assume that it's aligned. An Emacs built with ENABLE_CHECKING should verify any alignment issues already, as make_lisp_ptr checks for this. We don't need to worry about !USE_LSB_TAG on the trunk anymore, as support for abusing the high-order bits of pointers has been withdrawn on the trunk.