I think it will be helpful if it discusses internal fragmentation, where the payload is smaller than the allocated block. I observed that this was important in understanding the purpose of various memory allocation algorithms when undertaking the malloc lab in college.
Memory Allocation
91–100 of 182 posts
Re: Memory Allocation
#92A delightful page, written in a wonderfully interactive way.
My high congratulations for creating a most friendly, readable and useful lesson!
Re: Memory Allocation
#93Earlier quoted context omitted.
Yes, this is one of the things I look back on as a weak point in the writing. I wanted to make this a lot more clear but by the time I'd gotten to this point in the article, I'd sort of coded myself into a corner with the visualisation code. In another universe I'd hook in to the page scroll and highlight each block being referred to as I talk about it in the text. I'm probably not explaining that well here, but imag…
Couldn't you highlight each block being referred to as you mouse over / click on relevant text? (The latter might not be terribly hard to do with and CSS :target, if you can give the blocks ids.)
The blocks aren't HTML elements, they're drawn on to a canvas. It _could_ be possible regardless, though. I may revisit this. Thanks for the idea! :)
Re: Memory Allocation
#94> When we free memory, we should make sure that if the block we return to the free list is next to any other free blocks, we combine them together. This is called "coalescing." A little offtopic but the default Delphi 7 memory allocator did this, except that it also merged blocks that it obtained from different OS allocation calls. This worked fine for regular usage, but if that memory was ever used for Bitmaps for U…
I think the far weirder part of this was the kernel-side handling of scrollbars
Re: Memory Allocation
#95Earlier quoted context omitted.
Could you elaborate on what you mean?
It talks about how a simple malloc implementation would doll out entries in a buffer of memory and manage free lists, but not how the implementation actually gets that buffer from the operating system, or return it to the system when done (mmap, munmap, for example).
Ahh yes, I'm with you now.
I made a deliberate choice to not include that, mostly due to post size/complexity reasons. I decided that the focus of the piece was going to be on the task of effectively managing the memory you have in the face of calls to malloc/free. I decided against talking about any environment-specific information (brk, mmap, cache locality, multithreading, etc.)
May not have been the right call, but it kept the length fairly reasonable and I think it gives people enough of a nudge to dip their toes into the playground if they have time.
If you check the HTML comments on the page you'll find quite a lot of cut content. I wanted to do deep dives on real-world malloc implementations, but it ended up being very difficult to cover without making the post take over an hour to read.
Re: Memory Allocation
#96Earlier quoted context omitted.
I came here to see if anyone else noticed this and am confirming that there is a bug in the first slider on malloc(7). Indeed it only allocates two bytes instead of seven.
Good spot! Thank you. Fix on its way out now. :)
Thank you for building this! It's helped a lot for me to wrap my head around the concept even more deeply than before.
Re: Memory Allocation
#97> "There's no shortage of information about memory allocators on the Internet, and if you've read this far you should be well-placed to dive in to it.
Join the discussion on Hacker News! https://news.ycombinator.com/item?id=36029087 "
Interesting to use hacker news as the blog's own comment section in this way.
Re: Memory Allocation
#98This is a great article. I also recommend K&R Chapter 8 if people wanna know more. Do the exercises and it’ll just click.
Re: Memory Allocation
#99Earlier quoted context omitted.
Well shit. I think you're right.
Oh another thing, I'm not a fan of the premise: "As a general-purpose memory allocator, though, we can't get away with having no free implementation." I have a belief that the future of software are short-lived programs that never free memory. Programs allocate and terminate. Short-lived program communicate with each other via blocking CSP-style channels (see Reppy's Concurrent Programming in ML). If you could also e…
My take on this is that code should always match up malloc and free, but your application may use an allocator where free is noop, if that's appropriate for the application you write. This way your code is more generic and can be reused in an other application with different constraints.
And as soon as you are replacing free, you can replace malloc as well to be optimized for your use case. No need to build difficult bookkeeping hierarchies when they will never get used.
Re: Memory Allocation
#100This is wonderful! I'm definitely going to be sharing this with my students (college sophomores studying CS). If I were to make some suggestions, based on how I know they would receive this: - I would make explicit reference to heap and stack. Students who are learning this material are learning about the heap/stack dichotomy, and I think it would really improve the exposition to make clear that not all memory is all…
Really appreciate you taking the time to write this, thank you. I tried a couple of different ways to introduce the stack and the heap but it always felt like it made the post too long and complicated. In the end I decided to take a pure, idealistic view of memory in order to focus on the algorithms used to pack allocations effectively. You can see some of my abandoned efforts as HTML comments in the post :D Introduc…
Please do, this excellent post is already a good start on the issues involved in creating compacting garbage collectors.