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: Proposal: block-based vector allocator Date: Thu, 31 May 2012 17:16:12 -0400 Message-ID: References: <4EDDA68B.5050601@yandex.ru> <4FB4AFA4.7020601@yandex.ru> <4FBA32D9.5090704@yandex.ru> <4FC775B5.30904@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1338498983 23181 80.91.229.3 (31 May 2012 21:16:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 31 May 2012 21:16:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 31 23:16:22 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 1SaCjF-0003ns-FS for ged-emacs-devel@m.gmane.org; Thu, 31 May 2012 23:16:21 +0200 Original-Received: from localhost ([::1]:56868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaCjF-0006GL-4h for ged-emacs-devel@m.gmane.org; Thu, 31 May 2012 17:16:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaCjC-0006GE-TP for emacs-devel@gnu.org; Thu, 31 May 2012 17:16:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SaCjA-0004hc-60 for emacs-devel@gnu.org; Thu, 31 May 2012 17:16:18 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaCjA-0004gZ-07 for emacs-devel@gnu.org; Thu, 31 May 2012 17:16:16 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q4VLGCGs021631; Thu, 31 May 2012 17:16:12 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id B5F0FB4078; Thu, 31 May 2012 17:16:12 -0400 (EDT) In-Reply-To: <4FC775B5.30904@yandex.ru> (Dmitry Antipov's message of "Thu, 31 May 2012 17:44:21 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4238=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4238> : streams <763050> : uri <1122225> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:150700 Archived-At: > +#define VECTOR_BLOCK_SIZE 4096 This needs a comment explaining the choice of constant. E.g. it should say that the code makes no particular assumption about this constant, so it does not have to be a power of 2. > + /* On a 32-bit system, rounding up vector size (in bytes) up > + to mult-of-8 helps to maintain mult-of-8 alignment. */ > + roundup_size = 8 IIUC what the comment should say is something more like "Used to ensure alignment (e.g. LSB_TAG requires this to be a multiple of 8), as well as reduce the size of the vector_free_lists array". > +#define VECTORS_PER_BLOCK_MAX \ > + (VECTOR_BLOCK_BYTES / sizeof (struct vectorlike_header)) Unused. > +/* We maintain one free list for each possible block-allocated > + vector size, and this is now much of the free lists we have. */ Should "now much of the" be replace by "the number of"? > +struct vector_block > +{ > + unsigned char data[VECTOR_BLOCK_BYTES]; > + struct vector_block *next; > +}; Wouldn't it be easier to define VECTOR_BLOCK_BYTES to be an arbitrary constant, and then VECTOR_BLOCK_SIZE to be "sizeof (struct vector_block)"? > - return (p == m->start && m->type == MEM_TYPE_VECTORLIKE); > + if (m->type == MEM_TYPE_VECTORLIKE) > + { > + if (m->end - m->start == VECTOR_BLOCK_BYTES) Please just use a new MEM_TYPE, so we don't need to worry about the possibility of having a non-vector-block which just happens to have the same size as a vector-block. Other than that (and Paul's comments), this looks good, thank you very much, Stefan