OSDev.org

Hey ho,

where should I define the MORECORE macro to make newlib use my custom function instead of sbrk? (is it the right way for the following?)

I want to use a different memory model, and for sbrk I must have one contiguous area.. but instead I want to give malloc a different way to get new chunks, but how can I define that?

Thanks

max wrote:for sbrk I must have one contiguous area..

Although everybody just make a linear grow for program break, there is nothing stop you to return non-continuous addresses per each call.
(disclaimer, I have not tested it, but the interface of sbrk permit doing so).

bluemoon: That's wrong, that's not how sbrk works.

I think this was discussed on #osdev at irc.freenode.net yesterday (probably the same author as this thread).

sortie wrote:bluemoon: That's wrong, that's not how sbrk works.

I think this was discussed on #osdev at irc.freenode.net yesterday (probably the same author as this thread).

Yep sortie, that was me well actually it really seems like there is no other (usable) solution, so I enabled paging with the following (flat) memory model:

There is one global page directory. It has the following layout (with example values [virtual addresses]):
- 0x00000000 - 0x00177000: Kernel area is identity mapped (calculated with linker symbols and the end of the ramdisk module)
- 0x00177000 - 0x1FEED000: Heap area is mapped as one big, contiguous area of memory (pointing to free chunks somewhere the memory), used as the global heap area

This allows me to just set the initial break to the start of the heap area (here 0x00177000), and then increase (or decrease) that address by the given value, and go out of memory if the end of the heap area is reached.

Just one question: Later, when I want to use DMA, I plan to reserve another identity-mapped area between the kernel and the heap area. So that should be no problem. But, is there anything else (when implementing drivers and stuff) that I maybe didnt plan here, and that could conflict with my memory model?

btw: I know that there is no security for processes, but thats on purpose.

As far as I remember, dlmalloc can be configured to use a mmap interface, rather that sbrk. I believe jemalloc does too. I don't know about others. You may want to investigate using one of these?

Regards,
John.

jnc100 wrote:As far as I remember, dlmalloc can be configured to use a mmap interface, rather that sbrk. I believe jemalloc does too. I don't know about others. You may want to investigate using one of these?

Regards,
John.

That would be a possibility, too. But I've implemented paging now, so that would be a step back

Hey, you'll be surprised, but you can use paging and a sane interface at the same time.

The biggest problem with sbrk() is that it leaves you open to a lot of fragmentation. For example, if you allocate 100 MB, then allocate a couple bytes, and then free the 100 MB, your process is still using 100 MB of fully-paged memory!

mmap allows the heap to have 'holes' of freed memory that can be filled - for the example case, the 100 MB might be one big mmap, then the couple bytes might be another mmap (but perhaps then split into smaller chunks). Then when you free the 100 MB allocation, the 100 MB can be freed.

Paging helps avoid the need for contiguous physical memory. mmap is not a step back; sbrk is a step back