> For performance reasons, malloc(3) will hold on to a number of pages
quoted text
> that theoretically could be given back to the kernel, simply because
> it expects to need them shortly.

Although the primary concern is malloc(), I would like to point out that=20
various programs implementing copying garbage collection could more=20
efficiently give memory back to the system than malloc(), and could therefo=
r=20
benefit more than malloc() from some kind of feedback from the kernel.

There was concern over the complexity involved with intelligently doing=20
something about the memory pressure hints in userspace, but this does not=20
apply here since the allocator/garbage collection would be the equivalent o=
f=20
malloc() and complexity there would not affect application code.

The problem with malloc() being that, unless I am missing something, malloc=
=20
will never be able to give back memory to the kernel except insofar as the=
=20
memory mapped is continuously unused between some location and the break (i=
n=20
the case of sbrk()) or over the entire range (mmap()). malloc() cannot forc=
e=20
this to be the case, since pointers must remain valid. The possibility of=20
reclamation is then often going to be limited to completely unused space=20
being held by malloc() for future use, rather than also applying to areas=20
already used for allocation.

Programs implementing copying GC, or able to for some other reason to move=
=20
allocated memory around, could compact the heap and give back left-over=20
memory. In some cases this would only entail a temporary improvement due to=
=20
defragmentation, but in others (such as a long-running program spiking in=20
memory use, only then to drop a lot of that memory) it could have a pretty=
=20
massive effect on memory use.

Where a malloc() using program might be unable to sbrk() or munmap() becaus=
e=20
there happens to be some left-over non-free piece of memory at the top of t=
he=20
mapped range, a GC could use indications from the system to ensure this is=
=20
not the case (depending on details of the implementation; for example,=20
compactation of tenured generations could be forced early, etc).

(This is not to say I am aware of any implementation that actually supports=
=20
this, but on the other hand perhaps that is due to the lack of operating=20
systems that provide the required feedback.)

=2D-=20
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org