[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Eli Zaretskii
Date: Sat, 24 Oct 2009 12:05:31 +0200

> Date: Fri, 23 Oct 2009 16:10:47 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > From: Andreas Schwab <address@hidden>
> > Date: Fri, 23 Oct 2009 13:39:37 +0200
> > Cc: address@hidden
> > 
> > Eli Zaretskii <address@hidden> writes:
> > 
> > > Isn't the current definition of BASE_PURESIZE too large?
> > 
> > Fits quite well here (pure_size - pure_bytes_used == 79770).
> What configuration is that?
> Anyway, the numerical constant is not supposed to be tuned to the
> largest user of pure[], that's what SYSTEM_PURESIZE_EXTRA and friends
> are for.
> But since Dan says he has changes in the pipe to use that up, I guess
> that's okay.

After Dan committed his changes that use more purecopy, and after this

  2009-10-23  Andreas Schwab  <address@hidden>

          * puresize.h (PURESIZE_RATIO): Decrease to 11/7.

pure space overflows on a 64-bit GNU/Linux host, and I need to enlarge
the 1430000 constant to at least 1460000, i.e. by 30KB, to fix that.
On a 32-bit Windows, the old constant of 1430000 still works (there's
70KB of spare pure space in the dumped Emacs).  So I'm not sure if the
problem is with the ratio or with something else.

For the record, the extra use of purecopy caused the pure_bytes_used
value to go up by 52KB on 32-bit Windows, and by 92KB on 64-bit
GNU/Linux.  So it looks like the ratio is actually closer to 9/5 than
to either the old 10/6 or the new 11/7.  Or maybe I'm missing

reply via email to

[Prev in Thread] Current Thread [Next in Thread]