Application memory allocation

[DarylD]

How are people doing user application memory allocation/deallocation etc?

At the moment I obviously have a kalloc/kfree function for kernel usage, which is also accessible (in theory) to user applications through an interrupt. But I am sure this will pretty soon become inefficient.

I was thinking that an application could use an area of its reserved memory space (maybe 0x60000000 - 0x80000000 for example) and use its own libc allocation routines on this area.

Any other thoughts?

I will obviously continue to use my int 0x90/int 0x91 routines for now as they work and are reasonably efficient except for the interrupt overhead (which ultimately will kill the OS due to context switching).

Daryl.

[Pype.Clicker]

what is usually done is having two commands to increase/reduce the size of the application heap. When you malloc(N) and that the library malloc function can't find N bytes in the memory it already asked from the OS, it will ask the kernel to make the application's heap grow by M>N and allocate N bytes in the new chunk.
Similarily -- but seldom used -- the malloc function could decide it doesn't need so much space and tell the OS to size down the segment or free pages ...

[Tim]

I provide VmmAlloc and VmmFree functions to allocate areas of memory in page-sized chunks. When malloc runs out of memory, it calls VmmAlloc to allocate a new chunk for the heap, and starts allocating memory from there.

[amirsadig]

it will ask the kernel to make the application's heap grow by M>N and allocate N bytes in the new chunk.

is kernel will increse the heap with only M bytes or M is Multible of 4096 bytes. when M is only the requested size, that mean there is no need for malloc! exactly malloc should be only rapper function for sbrk() system call for example. then the memory manager in kernel will eat more space in the memory as when we increse the heap of the program with a multiple of 4096 and let malloc of the user library does the rest.

[Pype.Clicker]

the need for malloc remains for the following reason:
1. calling the OS for every small malloc() is inefficient.
2. the sbrk-like function just ensure bottom-up allocation, but cannot handle cases like x=malloc(); y=malloc(); free(x);
3. anything else i didn't thought about

[amirsadig]

1. calling the OS for every small malloc() is inefficient.

that what I have mentioned before. what is minimum number of byte the kernel can allocated for user heap?

2. the sbrk-like function just ensure bottom-up allocation, but cannot handle cases like x=malloc(); y=malloc(); free(x);

therefor I have said before?, it ?s better to let sbrk() allocate a multiple of 4096 byte and user implement over that malloc(), free(), ..., surely in libc

[Pype.Clicker]

oops ... sorry ... i was in some parallel world when i typed this ::)