I did not deeply research and test if it could be true or not.
I've following question: If I say malloc(1) I allocate 1 Byte from the Heap, but is this one byte logical what I'm believing or really physical?
When I work on 32-bit system and I want to increment from address to address, there is the counting 4-Bytes and so on and
you could not go by one bytes.
What I mean is, if you want to get one bytes from heap, you have already used 4-Bytes physically, which means, 1 Byte is used
and the rest also allocated but not useful or is there a mechanism which can also make the rest useful?
Any idea?
malloc(1)
Re: malloc(1)
it depends on the actual implementation of malloc(). The stock version on most system will actually allocate more memory for header and footer, for example, to record allocated size, padding, and safety guard patterns. Features and speed out-weighted a few bytes budget.
Having said that, you may still implement your own malloc() which try to utilize every single bytes and do no padding (but I guess some header is not avoidable), and it will not be optimal for speed.
However, in case you need to call malloc(1) many time, before you try to optimize malloc(1) for your use-case, you may as well re-design your program logic to avoid such need in the very beginning.
Having said that, you may still implement your own malloc() which try to utilize every single bytes and do no padding (but I guess some header is not avoidable), and it will not be optimal for speed.
However, in case you need to call malloc(1) many time, before you try to optimize malloc(1) for your use-case, you may as well re-design your program logic to avoid such need in the very beginning.
-
piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: malloc(1)
How often will you need to malloc 1 byte? At that point you might as well just create a global variable and be done with it.
But yes, it depends. My malloc doesn't allocate memory that specific. The smallest size you can go is 32 bytes (and there aren't any headers or anything). In a cost-benefit look, you'd have a lot of memory just to index and keep track of all these 1 byte slots, and it would make malloc slower in some implementations. It wouldn't be worth it to keep memory slots that small. So if you call malloc(1) (say, in my implementation), the call works perfectly and you get a pointer back. However, the actual space you can use before overwriting memory that isn't yours is 32 bytes.
-JL
But yes, it depends. My malloc doesn't allocate memory that specific. The smallest size you can go is 32 bytes (and there aren't any headers or anything). In a cost-benefit look, you'd have a lot of memory just to index and keep track of all these 1 byte slots, and it would make malloc slower in some implementations. It wouldn't be worth it to keep memory slots that small. So if you call malloc(1) (say, in my implementation), the call works perfectly and you get a pointer back. However, the actual space you can use before overwriting memory that isn't yours is 32 bytes.
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: malloc(1)
Aside from the fact that there are several (non-IA32) CPUs around that would balk at a 32bit value written at an address not divisible by 4 (i.e., such code being non-portable)...
...if you need to address a certain amount of memory byte-wise, just malloc() a chunk of memory of the appropriate size, and write your own function passing out one byte at a time from that chunk.
On the global scale, malloc(1) simply doesn't make sense. Allocating memory is a costly operation, and doing it a byte at a time just makes it more expensive.
...if you need to address a certain amount of memory byte-wise, just malloc() a chunk of memory of the appropriate size, and write your own function passing out one byte at a time from that chunk.
On the global scale, malloc(1) simply doesn't make sense. Allocating memory is a costly operation, and doing it a byte at a time just makes it more expensive.
Every good solution is obvious once you've found it.
Re: malloc(1)
Ok, so I'm going to tack this question on to the end of this thread and maybe someone can point me to a good tutorial or give me a good understanding which jumps off that "ah-ha" moment.
I read this http://www.osdever.net/tutorials/view/m ... nagement-1 tutorial and I'm wondering if my understanding of the stack and of malloc() is correct.
From what I took away the stack can be a global variable in my kernel.cpp let's call it stack[] and when I want to allocate more memory I will call malloc() correct?
If the above is true would it be good practice to have my malloc() search stack[] until it finds the first free byte and then allocate from there?
Do you recommend writing malloc in c or asm?
I read this http://www.osdever.net/tutorials/view/m ... nagement-1 tutorial and I'm wondering if my understanding of the stack and of malloc() is correct.
From what I took away the stack can be a global variable in my kernel.cpp let's call it stack[] and when I want to allocate more memory I will call malloc() correct?
If the above is true would it be good practice to have my malloc() search stack[] until it finds the first free byte and then allocate from there?
Do you recommend writing malloc in c or asm?
Re: malloc(1)
Nope.kr651129 wrote:...I'm wondering if my understanding of the stack and of malloc() is correct.
Nope, stack is automatically allocated at function entry / variable definition, and removed at function return / variable leaving scope. The upper bound of stack memory is defined by the stack segment, and the current "fill mark" of the stack is %esp (on IA32). Note that stack extends downward. None of this has to be done manually, except if you're doing ASM.From what I took away the stack can be a global variable in my kernel.cpp let's call it stack[]...
malloc(), on the other hand, allocates memory on the heap, which traditionally is located in memory after your binary, growing upward.
It should be obvious from the above that malloc() and stack are two disjunct concepts.If the above is true would it be good practice to have my malloc() search stack[] until it finds the first free byte and then allocate from there?
C, unless you're writing an ASM OS.Do you recommend writing malloc in c or asm?
Every good solution is obvious once you've found it.
Re: malloc(1)
I'm having a lot of trouble with the stack. I've put together a malloc of my own but I want to have a better understanding. Any tutorials you guys recommend?
Re: malloc(1)
kr651129, the 'stack of pages' in that article has absolutely nothing to do with the 'stack' that your user programs or kernel use that is pointed to by the ESP register.
If you are not 100% clear about what a stack is, what a stack of pages might be or how malloc works, then I'm afraid that article won't help you.
If you are not 100% clear about what a stack is, what a stack of pages might be or how malloc works, then I'm afraid that article won't help you.
If a trainstation is where trains stop, what is a workstation ?