From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: USE_LSB_TAG and MS-DOS Date: Tue, 18 May 2004 20:45:37 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <8011-Tue18May2004204536+0300-eliz@gnu.org> References: <2719-Sat15May2004150718+0300-eliz@gnu.org> <2914-Tue18May2004170058+0300-eliz@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1084909123 4864 80.91.224.253 (18 May 2004 19:38:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 May 2004 19:38:43 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 18 21:38:30 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQAQ2-0001v4-00 for ; Tue, 18 May 2004 21:38:30 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQAQ1-0002xz-01 for ; Tue, 18 May 2004 21:38:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQA2Y-0000Fc-KY for emacs-devel@quimby.gnus.org; Tue, 18 May 2004 15:14:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQA2S-0000F0-KD for emacs-devel@gnu.org; Tue, 18 May 2004 15:14:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQA1w-0000As-Ne for emacs-devel@gnu.org; Tue, 18 May 2004 15:14:07 -0400 Original-Received: from [192.114.186.23] (helo=aragorn.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQ9Va-0002qK-9j for emacs-devel@gnu.org; Tue, 18 May 2004 14:40:10 -0400 Original-Received: from zaretski ([80.230.149.238]) by aragorn.inter.net.il (MOS 3.4.6-GR) with ESMTP id CXD18951; Tue, 18 May 2004 20:46:52 +0300 (IDT) Original-To: Stefan Monnier X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: (message from Stefan Monnier on 18 May 2004 11:13:47 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23651 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23651 > From: Stefan Monnier > Date: 18 May 2004 11:13:47 -0400 > > >From the ChangeLog text it seems that cmpiling with USE_LISP_UNION_TYPE > would have caught that eons ago. Probably. Alas, I have no resources to do such experiments with the DOS port, unless I have a specific bug and a good reason to believe that some non-standard switch will help me find it. (I did compile with ENABLE_CHECKING, as you suggested, but that didn't help to hunt this specific bug, as Emacs crashed in precisely the same place as before. I then used GC debugging techniques described in etc/DEBUG to find that Emacs was marking dos-unsupported-char-glyph and barfed when it saw 127 as a cdr of a cons cell.) Anyway, having to look for this bug was an ample punishment, as it was I who introduced dos-unsupported-char-glyph years ago, and its incorrect initialization is my bad. > > Btw, is pure[] usage supposed to go up when USE_LSB_TAG is in effect? > > AFAICS, it went from 977KB to 1019KB with almost no changes in Lisp > > files since the previous build. > > There is likely to be an increase of about "2bytes * nb objects" due to the > additional alignment constraint. Actually, most objects have a size that's > a multiple of 8, so the extra alignment should only happen after allocating > an array or a string, so it's probably more like "2b * nb arrays-or-strings". Hmm... the last garbage-collect that is run at the end of `loadup' says: ((48784 . 10021) (10244 . 0) (543 . 60) 69410 144160 (48 . 16) (17 . 12) (4927 . 1814)) 4900 strings is far too few to explain 40KB growth of pure storage, so where else is the extra storage coming from? (Should PURESIZE's value be enlarged when USE_LSB_TAG is in effect?)