From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Quesition about Lisp_Vector Date: Sat, 12 Nov 2011 20:02:10 -0500 Message-ID: <32F6D3E9-2729-4F39-8F5D-4604DDF829AB@raeburn.org> References: <553A1AC5-4002-4175-AD1F-CC596356E44C@raeburn.org> <87ty6aj9al.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1321146143 29268 80.91.229.12 (13 Nov 2011 01:02:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 13 Nov 2011 01:02:23 +0000 (UTC) Cc: Qiang Guo , emacs-devel@gnu.org To: Stephen J. Turnbull Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 13 02:02:18 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 1RPOSf-0005xz-Re for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2011 02:02:17 +0100 Original-Received: from localhost ([::1]:49408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPOSf-0003M0-3q for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2011 20:02:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:46297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPOSc-0003Lr-LP for emacs-devel@gnu.org; Sat, 12 Nov 2011 20:02:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RPOSb-0000pG-1g for emacs-devel@gnu.org; Sat, 12 Nov 2011 20:02:14 -0500 Original-Received: from mail-gx0-f169.google.com ([209.85.161.169]:50902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RPOSa-0000p7-U7 for emacs-devel@gnu.org; Sat, 12 Nov 2011 20:02:13 -0500 Original-Received: by ggnq1 with SMTP id q1so1861622ggn.0 for ; Sat, 12 Nov 2011 17:02:12 -0800 (PST) Original-Received: by 10.236.116.9 with SMTP id f9mr5956880yhh.0.1321146132238; Sat, 12 Nov 2011 17:02:12 -0800 (PST) Original-Received: from squish.raeburn.org (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id c10sm24045672yhj.2.2011.11.12.17.02.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 17:02:11 -0800 (PST) In-Reply-To: <87ty6aj9al.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.161.169 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:146020 Archived-At: On Nov 11, 2011, at 22:42, Stephen J. Turnbull wrote: >> a long time, and it works on most if not all C compilers. >=20 > clang (llvm) warns about accesses with a constant index greater than > zero, but it works. Good point. In terms of complaints, I was thinking more about the = detection of run-time indexes greater than zero. I've used one = implementation that either interpreted C or compiled with extensive = run-time checks (not that it matters which), that probably would've = flagged the reference at run time for checking, but I don't recall for = sure. (It was a couple decades ago.) I expect something like valgrind = wouldn't have enough information to detect it. > Ah, now that interests me. If there actually is such space, most > constant index accesses are to a[1], and in theory we could allocate > array space to fill out the padding. However, since the structure > alignment requirement is usually no more than sizeof(pointer), which > is the same as sizeof(Lisp_Object), and IIRC all of the Lisp_Vectors > warned about are general (ie, the elements are Lisp_Objects), we > probably don't buy anything. Right, in practice in this case it's not likely to save us anything on = most platforms. But an implementation could have rules like "structures = over 8 bytes get 16-byte alignment" (assuming 32-bit pointers), in which = case there would be wasted space at the end. On the other hand, the = rules could also say that larger arrays get stricter alignment, which = (in other use cases, probably not this one) could cause an attempt to = utilize that extra space to instead introduce padding before the array. The C99 spec for flexible array members is even written to give the = implementation some flexibility regarding this; it can place the member = as if it has some unspecified size chosen by the implementation, with = the alignment and padding rules following from that choice. > I wonder if there is any real loss to allocating two or three elements > in the base structure (ie, how often vectors of length less than three > or four are used). Instrumenting the GC code would be an easy way to find out how many are = live at any given GC point, assuming the size fields don't lie. Ken=