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: [PATCH] shrink struct vectorlike_header Date: Thu, 11 Oct 2012 08:57:09 -0400 Message-ID: References: <50766A2C.8070705@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349960248 2285 80.91.229.3 (11 Oct 2012 12:57:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Oct 2012 12:57:28 +0000 (UTC) Cc: Emacs development discussions To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 11 14:57:32 2012 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 1TMIKR-0008C1-Ol for ged-emacs-devel@m.gmane.org; Thu, 11 Oct 2012 14:57:31 +0200 Original-Received: from localhost ([::1]:39981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMIKL-0008Dl-84 for ged-emacs-devel@m.gmane.org; Thu, 11 Oct 2012 08:57:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMIKD-0008DY-LP for emacs-devel@gnu.org; Thu, 11 Oct 2012 08:57:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMIK7-0005vF-JX for emacs-devel@gnu.org; Thu, 11 Oct 2012 08:57:17 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:50277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMIK7-0005v2-GC for emacs-devel@gnu.org; Thu, 11 Oct 2012 08:57:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLQG/2dsb2JhbABEtBGBCIIVAQEEAScvIwULCw4mEhQYDSSIHAW6CYsbhSkDnjmEeoFYgwWBOg X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="201088550" Original-Received: from 69-196-180-6.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Oct 2012 08:57:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8FFE259510; Thu, 11 Oct 2012 08:57:09 -0400 (EDT) In-Reply-To: <50766A2C.8070705@yandex.ru> (Dmitry Antipov's message of "Thu, 11 Oct 2012 10:41:48 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.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:154285 Archived-At: > This is an attempt to shrink struct vectorlike_header to the only > 'size' field. For pseudovectors, 'size' field is rearranged to have > one more bitfield to record the size of non-Lisp_Object area, thus > giving the possibility to calculate the memory footprint of any > vectorlike object. Thanks, this is a very welcomed change (which will have to wait for the freeze to end, of course). > +/* When V is on the free list, V->contents[0] is used as a pointer to > + next vector on the free list. */ > + > +#define NEXT_IN_FREE_LIST(v) \ > + (*(struct Lisp_Vector **)((char *) v + header_size)) Please make the code match the comment, e.g: (*(struct Lisp_Vector **)&(v->contents[0])) > +/* For the large vector V, previous word is used as a pointer > + to next large vector. */ > + > +#define NEXT_LARGE_VECTOR(v) \ > + (*(struct Lisp_Vector **)((char *) v - sizeof (void *))) You could also use the simpler: (((struct Lisp_Vector **)v)[-1]) > +/* Convert from memory block used for large vector to the vector itself. */ > + > +#define LARGE_VECTOR_START(mem) \ > + (struct Lisp_Vector *)((char *) mem + sizeof (void *)) > + > +/* Convert from large vector to it's memory block. */ > + > +#define LARGE_VECTOR_MEM(v) (void *)((char *) v - sizeof (void *)) Why not define a struct large_vector, so that NEXT_LARGE_VECTOR can be (VECTOR_TO_LARGE (v)->next), LARGE_VECTOR_START (renamed to LARGE_TO_VECTOR) can be (&(mem->vector)), and LARGE_VECTOR_MEM (renamed to VECTOR_TO_LARGE) is defined maybe in terms of offsetof(vector)? > +static ptrdiff_t > +vector_nbytes (struct Lisp_Vector *v) > +{ > + ptrdiff_t size = v->header.size & ~ARRAY_MARK_FLAG; > + > + if (size & PSEUDOVECTOR_FLAG) > + { > + if (PSEUDOVECTOR_TYPEP (&v->header, PVEC_BOOL_VECTOR)) > + return (bool_header_size > + + (((struct Lisp_Bool_Vector *) v)->size > + + BOOL_VECTOR_BITS_PER_CHAR - 1) > + / BOOL_VECTOR_BITS_PER_CHAR); > + return (header_size > + + ((size & PSEUDOVECTOR_SIZE_MASK) > + + ((size & PSEUDOVECTOR_REST_MASK) > + >> PSEUDOVECTOR_SIZE_BITS)) * word_size); > + } > + return header_size + size * word_size; I'd put an "else" before this last "return", so that if you forget a "return" somewhere in the first branch of the "if", GCC will tell you. > + PVEC_TYPE_MASK = 0x3f << PSEUDOVECTOR_AREA_BITS, Please add a note where we define all the PVEC_foo types that the max number of such types is limited by this 0x3f. Stefan