Re: Question about the garbage collector.
- Hi there.
> [snip snip]Thanks, I've printed the paper out and will have a look.
> ... But SmallEiffel does *NOT* give back memory to the system.
> Instead it keeps it for further use.
> You may see that by reading one of the excellent papers produced
> by the SE team: "Compiler Support to Customize the Mark and Sweep
> Algorithm". It is available on the SmallEiffel site.
At the risk of asking a question that is answered in the paper, is it
possible to force the GC to give the memory back to the system? Let's say
I'm writing a wordprocessor which can handle files of 50MB+. If I opened
and closed a file of that size wouldn't that mean that the SIZE of the
program would now be sitting around 50MB?
Phil Malin, Senior Systems Engineer | | For each one who asks
Research & Technology, Melbourne IT | --+-- receives; and he who
207 Bouverie St,Carlton,Australia 3053 | | seeks finds; and to him
ph: +613-9344-0947 | | who knocks it shall be
fax: +613-9347-9473 | opened. Mat 7:8
- On Tue, Nov 30, 1999 at 09:09:52PM +1100, Philip Malin wrote:
> > My own simple test, allocating and freeing a block of 32KB, shows anThat makes a big difference. The system malloc/free system in
> > initial increase on the first malloc, and then no change thereafter. The
> > calls to free() are not returning the memory to the system.
> That's interesting. I'm running FreeBSD 3.1 (if that makes any
FreeBSD 3.x is quite different to most other systems, and is
tightly integrated into the VM system (malloc's are done with
anonymous mmap() calls, rather than the traditional sbrk()).
What's more, free() _will_ release memory to the system. What's
more, malloc() will _not_ necessarily consume the memory you
request, but calloc() will. Memory _space_ is allocated, but
backing pages are only allocated on demand. The whole system
uses a vigerous over-commit policy.