From xemacs-m  Mon Jul  7 22:21:24 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id WAA14192
	for <xemacs-beta@xemacs.org>; Mon, 7 Jul 1997 22:21:22 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.6/8.8.6) id UAA00477;
	Mon, 7 Jul 1997 20:24:04 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: Too small PURESIZE
References: <kig205a1kb5.fsf@jagor.srce.hr> <m2k9j2z8vj.fsf@altair.xemacs.org> <kigen9atm2b.fsf@jagor.srce.hr> <m2205az6qi.fsf@altair.xemacs.org> <kig3epqtjii.fsf@jagor.srce.hr> <m2hge6xphf.fsf@altair.xemacs.org> <kigu3i6s1t2.fsf@jagor.srce.hr>
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@xemacs.org>
In-Reply-To: Hrvoje Niksic's message of "08 Jul 1997 04:41:29 +0200"
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: 07 Jul 1997 20:24:04 -0700
Message-ID: <m23epqxm3v.fsf@altair.xemacs.org>
Lines: 89
X-Mailer: Gnus v5.4.62/XEmacs 20.3(beta12) - "Helsinki"

Hrvoje Niksic <hniksic@srce.hr> writes:

> To avoid recompiling alloc.c, it would have to not include
> puresize.h.

Not true.  Only avoiding puresize_adjust.h and referencing the
PURESIZE constant directly is enough.

> This would also mean that alloc.c does not know the PURESIZE.  Will
> it be able to function without knowing it?  Can all the stuff that
> needs to know PURESIZE be moved to pure.c?

A message from Kyle pushed me over the edge ...  see patch posted
separately.  Yes, alloc.c needs to know PURESIZE, no it does not need
to know it at compile time.

> Steven L Baur <steve@xemacs.org> writes:

>> > No, I'm getting two links on cold build, which seems to be correct.
>> > Still, I'd like for a way to get one link only -- and the second only
>> > if puresize is *really* insufficient -- like, if you add preloaded
>> > stuff.
>> 
>> > Would that be possible?
>> 
>> So long as the BASE_PURESIZE is set high enough, yes at the price of
>> an arbitrary amount of unused purespace.

> If this arbitrary amount is under 10K or so, this sounds like a good
> idea to me.

It isn't.  My first dump reveals:

Purespace usage: 1058220 of 1604000 (66% -- 532k wasted).

One of the major points of dynamic computation of PURESIZE is to free
the maintainer from doing the tedious hand computation (and half
dozen or so builds) everytime something changes in the dumped elisp.
Getting and keeping it somewhat close is still as hard.

>> You need to change the definition of `close enough' in alloc.c.

> I don't know what you mean; the code in alloc.c (in `check_purespace',
> to be precise) only checks whether the purespace has been exhausted,
> as reported by PURESIZE and pureptr.  The only way to make it not
> exhausted by default is to increase PURESIZE.  And the easiest way to
> do that is to adjust BASE_PURESIZE.

I am referring to the magic number `2' in the computation below (from
report_pure_usage in alloc.c), which decides how much surplus purespace
will be tolerated.

    {
      int lost = (get_PURESIZE() - pureptr) / 1024;
      char buf[200];

      sprintf (buf, "Purespace usage: %ld of %ld (%d%%",
               pureptr, (long) get_PURESIZE(),
               (int) (pureptr / (get_PURESIZE() / 100.0) + 0.5));
      if (lost > 2) {
                 ^
        sprintf (buf + strlen (buf), " -- %dk wasted", lost);
	if (die_if_pure_storage_exceeded) {
	  PURESIZE_h(pureptr + 16);
	  rc = -1;
	}
      }

      strcat (buf, ").");
      message ("%s", buf);
    }


> Do you think we should go for it?  I think it would be worth wasting
> a few K of memory for the decrease in confusion and complexity.

I don't know.  The closer we make the initial guess, the more
nightmarish maintenance becomes.  One size absolutely does not fit
all.

> Of course, if a site administrator adds stuff to dumped-lisp, the
> puresize adjustment mechanism will keep functioning -- so we'll still
> be better off than we were without it.

Making a looser fitting computation of PURESIZE will only benefit the
developer not the site administrator.
-- 
steve@calag.com baur
Unsolicited commercial e-mail will be billed at $250/message.

