From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: malloc and alignment Date: Mon, 16 Jun 2003 11:39:44 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306161539.h5GFdjMc011837@rum.cs.yale.edu> References: <200306161438.h5GEcodM011551@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1055778497 15778 80.91.224.249 (16 Jun 2003 15:48:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 16 Jun 2003 15:48:17 +0000 (UTC) Cc: Stefan Monnier Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jun 16 17:48:15 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Rw6Y-0003Py-00 for ; Mon, 16 Jun 2003 17:41:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19RwU1-0005Vp-00 for ; Mon, 16 Jun 2003 18:05:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Rw6M-0003lT-Uh for emacs-devel@quimby.gnus.org; Mon, 16 Jun 2003 11:40:58 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Rw5x-0003Eu-C7 for emacs-devel@gnu.org; Mon, 16 Jun 2003 11:40:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Rw5W-0002JT-Fq for emacs-devel@gnu.org; Mon, 16 Jun 2003 11:40:08 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Rw5B-0001tr-Px for emacs-devel@gnu.org; Mon, 16 Jun 2003 11:39:45 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h5GFdj0i011839; Mon, 16 Jun 2003 11:39:45 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h5GFdjMc011837; Mon, 16 Jun 2003 11:39:45 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: David.Kastrup@t-online.de (David Kastrup) Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15128 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15128 > > I'd like to try and get rid of the markbit on Lisp_Object values. > > The idea is to scrape off a few more bits (I'd like to bump maxint > > to 512MB instead of 128MB). And I'd also like to represent floats > > in 8bytes rather than 12. > > If you are scraping off bits, why not instead _add_ one, but reserve > _all_ the additional tag values gained in that way for representing > integers? > > Something like "tag byte values of 0 to 127 all represent integers, > tag byte values from 128 to 256 represent all other data types". > > That way integers would go up to 1GB without pain. We already eat 4bits of each pointer (and what's worse, we eat the topmost ones, and leave the unused 2 (or 3) lower bits untouched). If we eat more we'll bump even more quickly into the problem where Emacs can't allocate any more data because it has eaten up its address space (which is currently only 256MB large and would be reduce accordingly). We try to minimize the problem by allocating buffer-text separately, so buffer-text shouldn't eat into this address space, but it is still an important limitation (buffers eat up memory not only in terms of buffer-text but also things like text-properties, ...). Instead, I'd like to reduce those 4bits down to 3 (it's currently 3bits of tag plus one bit of marking, so removing the markbit will bring it down to 3) and maybe also make use of the 4-byte alignment of objects so we don't waste the lower 2bits (we can just shift the pointer by 2bits before adding our 3bits tag, so we only eat up the top bit. Or we can even impose an 8byte alignment, don't eat any pointer space at all, and just place the tag on the lower bits). Anyway, experimentation is needed first. Stefan "who always wished that 64bit architectures would use bit-addressing rather than byte-addressing, such that a natural 64bit alignment gives you 6 bits of tag space to play with" PS: The only reason why the markbit exists is because cons cells are made of 2 words only (not extra header), so when we mark them, we use one of the bits of the `car', but since any value can be in the `car', that means that this bit of a Lisp_Object value cannot be used for anything else. The markbit is not used to mark the Lisp_Object referenced, but to mark the object in which the Lisp_Object value is placed. PPS: I.e. in order to get rid of this mark-bit, we only need markbit bitmaps for cons-cells. But I also want to use them for floats in order to have a more efficient representation of floats (they are currently represented as a 64bit double plus a one-word header of which only one bit is used).