www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/04/19/06:53:45

Date: Sun, 19 Apr 1998 13:52:25 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc: djgpp AT delorie DOT com
Subject: Re: RHIDE and pentium cc1plus
In-Reply-To: <m0yQAQR-000S3EC@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.980419135156.23362I-100000@is>
MIME-Version: 1.0

On Fri, 17 Apr 1998, Salvador Eduardo Tropea (SET) wrote:

> The FACT is that gcc is sensitive to PHYSICAL memory, don't ask 
> me way or how, I really don't understand the effect. For some tasks
> gcc really needs PHYSICAL memory and all the virtual memory in the
> world doesn't help a bit.

I find this hard to believe.  Neither the compiler nor the library can
distinguish between physical and virtual memory, except at levels
below `malloc'.  Could you please post a program that caused the
compiler to behave this way?

> A good example in my system is that W95 some times eats enogh
> physical memory to make fail my compiling, under plain DOS the same
> is when RHIDE uses 2Mb more than normally (for example: too much
> editor opened and InfView with a huge info file, or debug info
> loaded in memory).

I routinely leave Emacs to run for several days on end, doing
everything from within it, including compilations.  This usually
causes it to stabilize at 20MB after a couple of days (I have several
huge files loaded into it permanently).  But I have never seen a case
of compilation which failed from Emacs but worked from the DOS
prompt.  All I see is some disk activity due to swapping.

> I don't understand why it happends because gcc uses malloc (or I'm
> wrong in it, could it use sbrk() for something?).

As far as I could see, gcc 2.7.2.1 only uses `sbrk' to report memory
usage.  So this shouldn't be the reason.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019