2023-06-26 11:05:52 <KipIngram   > So in Figure 4.3 here:
2023-06-26 11:05:54 <KipIngram   > http://f4bb1t.com/post/2020/12/12/doug-leas-memory-allocatordlmalloc-basics/
2023-06-26 11:06:25 <KipIngram   > What is the purpose of regarding the "chunk boundary" to be where they have it drawn (with the dahsed lines) instead of one slot downward?
2023-06-26 11:06:44 <KipIngram   > I don't get why they regard the last four bytes of the preceding chunk to be part of "this" chunk.
2023-06-26 11:07:25 <KipIngram   > I see why that field is important (when the chunk is free), but it feels more sensible to me to think of the chunks as "one row down" from how they've drawn them.
2023-06-26 11:09:26 <unjust      > not familiar with dlmalloc, but there's a question about exactly this on StackOverflow: https://stackoverflow.com/questions/38762396/why-dlmalloc-allocated-chunk-header-contains-4-bytes-of-previous-allocated-chunk
2023-06-26 11:11:19 <KipIngram   > Great - I'll go read that.
2023-06-26 11:12:44 <KipIngram   > Oh, I see.
2023-06-26 11:13:15 <KipIngram   > If you thought of it as in the preceeding chunk, then you'd logically "find it" by using the base address of the preceeding chunk, which would involve adding the size and so on.
2023-06-26 11:13:37 <KipIngram   > The way they have it, all references are from the low address of some chunk and are at fixed offset regardless of block size.
2023-06-26 11:14:08 <KipIngram   > That makes sense, and is probably how I'd wind up having done it even if it hadn't been drawn that way, but I do see what they're trying to convey.
2023-06-26 11:14:30 <KipIngram   > I'd have been likely to find that field as <base of next chunk> - 0x04.
2023-06-26 11:14:47 <KipIngram   > Whereas the way they've drawn it it's just at <base of next chunk>.
2023-06-26 11:15:11 <KipIngram   > Thanks for that; I was scratching my head.
2023-06-26 11:16:11 <unjust      > i learnt something too, i need to go read more about heap allocators
2023-06-26 11:16:11 <KipIngram   > And also it lets that field be part of a C structure instead of hanging out all alone at the end of a block.
2023-06-26 11:16:29 <KipIngram   > I studied boundary tag in college, but that was quite a long time ago.
2023-06-26 11:22:20 <KipIngram   > dlmalloc looks like a pretty simple idea.  Details aside, the main theme seems to be to maintain separate data structures for all of the different chunk sizes, and use the right one for each request.
2023-06-26 11:22:40 <KipIngram   > And then there would be splitting and coalescing at appropriate times.
2023-06-26 11:56:54 <veltas      > KipIngram: This is a better description https://gee.cs.oswego.edu/dl/html/malloc.html
2023-06-26 11:58:19 <KipIngram   > Cool, thanks.
2023-06-26 12:00:20 <veltas      > But yeah, the header on allocated chunks allows both traversal of the current size bucket, and coalescing of neighbouring chunks
2023-06-26 12:00:52 <veltas      > I'll have to write a dlmalloc for NewB, that would be a good demonstration!
2023-06-26 12:02:06 <veltas      > Sorry....... traversal of size bucket is totally incorrect, that only applies to free blocks and is not in the allocated header
2023-06-26 12:03:53 <veltas      > So it's just there to allow coalescing, we need to know how big a block is when we free/realloc it, so we know what we can/should coalesce, and to find the addresses of neighbours to check their headers too and whether they're free/allocated
2023-06-26 12:04:21 <KipIngram   > Right.
2023-06-26 12:05:18 <veltas      > And then actually whether we coalesce or not, when we free a block we want to know how big it is so we can add it to the right free blocks bucket
2023-06-26 12:06:37 <veltas      > I think Doug explained it best
2023-06-26 12:19:28 <KipIngram   > Yes.  It's an iterative thing - you free a small block, and that might lead to coalescing with its partner into the next larger list, and THAt might lead to coalescing with its partner, etc. etc.
2023-06-26 12:19:38 <KipIngram   > Up until you can't coalesce anymore.
2023-06-26 12:22:44 <thrig       > voltron when
2023-06-26 13:34:48 <KipIngram   > That's a really good write-up by Doug Lea.
2023-06-26 13:37:39 <KipIngram   > I'm going to generally follow his path (mostly).  I plan to write these in assembly, though - it's a core performance aspect.