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: Mon, 21 May 2012 16:12:45 -0400 Message-ID: References: <4EDDA68B.5050601@yandex.ru> <4FB4AFA4.7020601@yandex.ru> <4FBA32D9.5090704@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1337631178 24266 80.91.229.3 (21 May 2012 20:12:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 May 2012 20:12:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 21 22:12:58 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 1SWYyM-0006SX-0I for ged-emacs-devel@m.gmane.org; Mon, 21 May 2012 22:12:54 +0200 Original-Received: from localhost ([::1]:48287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWYyL-0003Sw-Ej for ged-emacs-devel@m.gmane.org; Mon, 21 May 2012 16:12:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWYyI-0003Rm-IE for emacs-devel@gnu.org; Mon, 21 May 2012 16:12:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWYyG-0002DE-P9 for emacs-devel@gnu.org; Mon, 21 May 2012 16:12:50 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:37461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWYyG-0002Cw-Kk for emacs-devel@gnu.org; Mon, 21 May 2012 16:12:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh0/O+K+j/2dsb2JhbAA3o0KBCIF1AQEEAVYjBQsLDiYSFBgNJIgTohGLeAUFBBhGDAODPgODcASjY4RY X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181640355" Original-Received: from 206-248-175-163.dsl.teksavvy.com (HELO pastel.home) ([206.248.175.163]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 21 May 2012 16:12:46 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9D027597A9; Mon, 21 May 2012 16:12:45 -0400 (EDT) In-Reply-To: <4FBA32D9.5090704@yandex.ru> (Dmitry Antipov's message of "Mon, 21 May 2012 16:19:37 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.143.162 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:150586 Archived-At: >>> +#define VECTOR_BLOCK_SIZE (4096) [...] >>> +/* One pointer is malloc overhead, others are BUMP and NEXT fields of struct >>> + vector_block. Rounding helps to maintain alignment constraints. */ >>> +#define VECTOR_BLOCK_BYTES \ >>> + (VECTOR_BLOCK_SIZE - roundup (3 * sizeof (void *), roundup_size)) >> Why do we care about malloc overhead? > IIUC, if/when we will have mmap()ed Lisp_Objects someday, this should help > malloc() to do direct mmap()/munmap() of page-size vector blocks. There are several conditions here, some of them might never actually happen. So I'd rather not worry about it for now. We can even define VECTOR_BLOCK_BYTES to some arbitrary constant and not worry about VECTOR_BLOCK_SIZE at all, then. >> BTW, if needed we could add a special case so there is only 1 vector of >> size 0 and (make-vector 0 ?) always returns that same vector (so it >> doesn't have to come from a vector_block). > Should we allocate it from pure space? Yes, we could do that. > As for the roundup() check, it looks like GNU/Linux and *BSD systems > both has it in sys/param.h, but (Open)Solaris uses sys/sysmacros.h. > So I'm trying to check for the most common case and then fall back > to simple default. Since it's a constant we can choose, we can choose that constant to be one that makes for efficient code. So I think we don't need to use some predefined macro but can code up our own, custom-designed for our specific needs, without worry about where various systems define `roundup'. Stefan