[haiku-development] Re: jemalloc has been ported to haiku. some discussion
- From: "François Revol" <revol@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 May 2008 19:02:59 +0200 CEST
> shortage of haiku's current malloc: it seems that the memory
> allocated
> will not give back to system at all when the app does not exit. If a
> long live app such as firefox allocate a large memory, use it and
> then
> free it. the memory now is not needed, but it can not be given back
> to
> system at all. It will cause lack of memory, also a lot of swap then
> a
> lot of harddisk I/O when swap available.
As long as the memory isn't touched again it should stay in the swap
once swapped out, there is no reason it would have any impact after
that point, except the loss of available pages.
> Some question about haiku's mm subsystem:
> 1.how can I get the amount of free memory? get_system_info (info)
> then
> info.used_pages? If so, a simplet test app(source is atached) implies
> that first, haiku's physical page allocation isn't the lazy one;
> second, current munmap does not actually free memory.
I believe munmap isn't implemented or not finished.
> 2.an area allocated by create_area, how can I free the leading part
> of
> the area? For the tailing part resize_area can be used.
>
> there are 2 ways of getting memory from system in current jemalloc
> ported to haiku:
> 1.anonymous mmap, but the munmap seems never give memory back to
> system
That must be fixed then.
> 2.resize_area, the same as current haiku's malloc. but it will race
> with threads that call create_area and resize_area on the same
> virtuall address range directly.
There is no reason, except a really stupid app forcing create_area to
use an address in front of the heap.
Sane apps let create_area() choose from an address range reserved for
this use, but of course it might get closer to the heap if it allocates
backward to it.
> PS:IMHO, there is no need to implement the the sbrk system call.
> For
> one thing, it is excluded from the POSIX.1 standard; for another,
> modern software does not use it any more.
I'm quite sure java uses it.
At least I've already seen and ported apps that did, sadly.
That doesn't mean we are forced to always allocate on the primary heap
area though.
But using mmap() each time allocates a different area, which isn't a
cheap op AFAIK.
François.
Other related posts:
