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:59:37 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306161559.h5GFxbw9011912@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 1055779765 23355 80.91.224.249 (16 Jun 2003 16:09:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 16 Jun 2003 16:09:25 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jun 16 18:09:22 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 19RwTo-0005fT-00 for ; Mon, 16 Jun 2003 18:05:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19RwrH-0005lD-00 for ; Mon, 16 Jun 2003 18:29:27 +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 19RwTB-0002R0-Ub for emacs-devel@quimby.gnus.org; Mon, 16 Jun 2003 12:04:33 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19RwOv-00022c-7D for emacs-devel@gnu.org; Mon, 16 Jun 2003 12:00:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19RwOT-00018i-78 for emacs-devel@gnu.org; Mon, 16 Jun 2003 11:59:42 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19RwOQ-00010i-5s for emacs-devel@gnu.org; Mon, 16 Jun 2003 11:59:38 -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 h5GFxb0i011914; Mon, 16 Jun 2003 11:59:37 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h5GFxbw9011912; Mon, 16 Jun 2003 11:59:37 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: David.Kastrup@t-online.de (David Kastrup) 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:15129 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15129 > > 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? Oh, I also forgot to mention that integers currently have 3bit of tag and 1bit of markbit, just like the rest and without getting rid of the markbit (what I'm trying to do), you can't go below a total of 2bits eaten (1bit of markbit and 1bit of tag). By getting rid of the markbit, we get the current count on integers down to 3bits eaten. We can trivially reduce it further because only 7 of the 8 tag values are currently used, so we can allocate the 8th one to int as well, so we are down to 2bit of tags for ints with only trivial changes to the code. That's where my 512MB number comes from. To bump it up to 1GB, we'd need to indeed extend the tag size on non-integers somewhat, which might not be that difficult, by the way, but we'll see about that later. BTW, someone on the XEmacs list recently complained that he had trouble opening a 755MB file. XEmacs supposedly handles up to 1GB buffers, but his Emacs process went up to 2.1GB (Mule begins by allocating a destination area of 1510MB because latin-1 has a max-expansion factor of 2), so I think that a 512MB limit due to integers might not be that bad, since bumping it to 1GB will just replace this limit with others. Stefan