common dynamic memory allocator API

[rdos]

Rdos, what on earth are you talking about ?

few, if any, allocators that grabs a piece of memory will ever be able to return some of it back to the OS, so linear address space that have been comitted for physical storage never free the physical storage.

That's not true. Many allocators including the malloc() that I use (from newlib) can munmap memory during free() if the O/S supports it. Most do.

OK, I didn't know that even if I tried porting to newlib a while ago. The OpenWatcom implementation does not contain any unmapping "hooks" that I know of at least.

Still, if memory is not allocated page-aligned, chances are it cannot be unmapped either. That is why malloc should work with page-aligned allocation for reasonably large allocations, and only resort to less for small.

[Solar]

@ Nick:

I fear we're still on shifting ground where naming is concerned. At least, I am a bit unsure what you mean when you say "allocator". "Memory manager" is another overworked term likely to cause confusion.

I'll try to come up with a definition of terms for this discussion; feel free to disagree, but we should use unambigious terms:

• Physical Memory Manager (PMM): Kernel code that handles page directories, page tables, page faults, swapping of memory to / from disk etc.
• Logical Memory Manager (LMM): Kernel code that handles memory allocations and deallocations, both from the kernel directly (kmalloc()) and from user-space system calls, and uses the PMM as backend.
• User Space Memory Manager (USMM): User-space code that takes user-space (de)allocation requests (malloc(), free(), new, delete, whatever), and makes appropriate system calls where necessary.

Physical and logical memory management can be done in one, or be kept seperate (for portability).

If I understand correctly, we're talking about a common API (wrapper) for the logical memory manager, i.e. how the logical memory manager is addressed, either by the kernel or by syscalls from the user-space memory manager when memory is to be allocated or de-allocated.

Correct?

[NickJohnson]

I primarily mean the logical memory manager, but it seems like an interface that works for the logical memory manager would also work for the userspace memory manager. They both seem to provide the same functionality, and would require the same sort of environment (i.e. some way to expand/contract). If that doesn't make sense, then I mean the logical memory manager.

[Solar]

The user-space MM offers, at the very minimum, malloc() on the frontend. On the backend it does a system call, which in turn would be addressing the logical MM.

So we're talking about the API addressed by the kernel and the user-space MM system call, and implemented by the logical MM.

Gosh, sometimes nailing down what we're talking about can be as difficult as the talking itself.

So, from the perspective of someone implementing a user-space MM:

I'd want to use that API to allocate chunks of memory in multiples of some "native" size (i.e., pages), and then pass them out in smaller parcels to the application (including doing the bookkeeping that involves). I would assume that those chunks are "worst-case aligned", and would want to pass back chunks that are no longer used by the application.

Hmmm...

Your API would work for my case. I don't really see the usefulness of heap_size(), though, and suspect that you had something different in mind here...?

[gerryg400]

There are a few other features that a logical memory manager might provide.

a) Support for 'shared' memory.

b) Allocate memory at a particular physical address.

c) Allow pages to be locked so that they are commited on allocation and cannot be paged out.

Am I off track here ? Not sure which part these things fit in.