Re: more question about porting/gcc

[Bernd Ebert <ebertbd@tick.informatik.uni-stuttgart.de>]

On Fri, 20 Mar 1998, Mario Becroft wrote:

> Really as far as I can see there are two problems here: One is that your
> memory slowly breaks up into more and more small blocks. The other is that
> gcc likes to use up all the RAM. Then there's the problem of starting up
> one app, then starting another before the first mshrinks, but I really
> can't see that being a problem in real life - since the program would use 
> mshrink so soon. Well I refer to the gcc problem above, but as for the
> fragmentation problem, it seems to me that this could be difficult to
> avoid, unless the amount of memory given to a process is limited. To do
> this the system needs to know how much RAM a process will need, before the
> process is started. Then the whole mshrink-problem is not relevant any
> more anyway, since it won't have to mshrink. The next best solution is the
> memory limit in mint.cnf as I explained above (assuming it doesn't limit
> Malloc as well, of course).
> 
> Am I making any sense here?

You are right about the fragmentation problem. Another solution to the
fragmentation-Problem is to rewrite Mint-Memory-Management and to page
all memory. Then we could do a better virtual memory and we could get rid
of fragmentation once and for all.
Concerning gcc: gcc does a mshrink, this is not the trouble. The trouble
is, that when compiling a big project gcc starts up and stops very often,
then the mshrink-Problem I described hits you. Sometimes you are able to
start another process, but if you are trying to do so while a newly
started gcc didn`t do its mshrink() it is crashing, that`s exactly what
could be avoided with the method I proposed the first time, just switch of
multitasking one or two ticks, then gcc (and of course every other
process) had enough time to do mshrink(). 

cu,
	Bernd