From: Archie Cobbs (archie@whistle.com)
Date: Tue Jan 05 1999 - 18:07:23 EST
Godmar Back writes:
> > Um, I can't remember. I think so. But shouldn't these get unmapped
> > when we're done with them anyway?
>
> I don't think so. How would we know when we're done, anyway?
> Also, I don't think it's an issue on modern systems that combine
> virtual memory and buffer cache anyway.
I think you're right about that last point. Probably it's no big deal.
> > Hmm.. so kaffe calls sbrk(2) directly? Why not just use malloc/free?
>
> Look at gc-block-mmap.c to see what kaffe does. I think it's sbrk()
> first, then it falls back on other possibilities. I think the idea here
> was to avoid fragmentation and overhead resulting from using malloc.
Hmm.. trying to outguess malloc() is not always a win. FreeBSD's
malloc allocates things in powers of two, so there is not really
a fragmentation problem. It also knows how to return free memory
to the system :-)
I wonder how many applications exhibit 'use lots of memory at the
beginning' behavior and would thus benefit from returning free memory?
> > Then when we freed enough memory, it would go back to the system.
>
> Well, it's not that easy. You'd also have to remove it from kaffe's
> primitive free list.
>
> We need a concept here -- maybe we should look at adapting/adopting Doug Lea's
> malloc()? This would give us memalign as well.
Hmm.. it's probably not worth a lot of worry at this point, and if
ever we wanted to change it at least the changes would be transparent
and limited in scope.. in other words, it falls under the category
of 'easy (potential) optimization later on'.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:29 EDT