3 ms·

I'm not an expert in memory allocation strategies, but AFAIK fragmentation can still be a problem with a naive allocator that doesn't group small allocations (l

I'm not an expert in memory allocation strategies, but AFAIK fragmentation can still be a problem with a naive allocator that doesn't group small allocations (less than a page size) into buckets. You won't run out of virtual address space (as was the case with 32-bit processes on computers with much more than 4 GB physical memory), but you may run out of physical memory if the allocator is "blocking" a whole memory page from being recycled because there's a tiny live allocation in it.

mort96 3y ago
Segmentation isn't fragmentation. "Segmentation" is when you have a machine with 16 bit machine words, which would usually mean you can only address up to 2^16 = 65536 bytes of memory, but you want to support up to 1 MiB of RAM so you add a segment register and read all memory reads as relative to (segment register << 4) so that you support up to 20 bit memory addresses. (The details differ of course, but this is how Intel did it.) This results in a split between "near pointers" and "far pointers". "Near pointers" are pointers which are 16 bit and assumed to be relative to the "current segment", and can thus be dereferenced directly with any memory load instruction. "Far pointers" are 32 bit and carry a segment part and a relative part, and to dereference it, you must first write the segment part to the segment register, then do the memory load instruction with the relative part, and then you probably wanna clean up after yourself by restoring the segment register to its old state. There were multiple segment registers too, one used for data ("heap") memory operations, one for stack memory operations, one for reading machine code, and some extra segments for convenience. You had to remember which of the segment registers your near pointer was supposed to be relative to. If this all sounds very tedious... well, it was, and that's why, yes, segmentation is still viewed as terrible :) (I wasn't around back when this was common, but I did write some 16-bit real mode code for a bootloader for an OS course once, and I have designed and implemented some toy 8 bit CPUs which used segmentation to have more than 256 bytes of RAM, so I do have some experience with it)
- flohofwoe 3y ago
  Ah right, I totally misread segmentation as fragmentation, sorry. IMHO a more flexible segmentation system (exposed as base-pointer plus offset) wouldn't actually be bad if properly supported by high level languages. You could treat the base pointer as 'private knowledge' inside a system and only hand out the offset as a 'public handle'. To access a specific address you need both the private base pointer and public offset handle, and the base pointer could also move around without invalidating the offset handles in the wild. Of course all this can be done purely in software too already.

mort96 3y ago

Segmentation isn't fragmentation. "Segmentation" is when you have a machine with 16 bit machine words, which would usually mean you can only address up to 2^16 = 65536 bytes of memory, but you want to support up to 1 MiB of RAM so you add a segment register and read all memory reads as relative to (segment register << 4) so that you support up to 20 bit memory addresses. (The details differ of course, but this is how Intel did it.) This results in a split between "near pointers" and "far pointers". "Near pointers" are pointers which are 16 bit and assumed to be relative to the "current segment", and can thus be dereferenced directly with any memory load instruction. "Far pointers" are 32 bit and carry a segment part and a relative part, and to dereference it, you must first write the segment part to the segment register, then do the memory load instruction with the relative part, and then you probably wanna clean up after yourself by restoring the segment register to its old state. There were multiple segment registers too, one used for data ("heap") memory operations, one for stack memory operations, one for reading machine code, and some extra segments for convenience. You had to remember which of the segment registers your near pointer was supposed to be relative to. If this all sounds very tedious... well, it was, and that's why, yes, segmentation is still viewed as terrible :) (I wasn't around back when this was common, but I did write some 16-bit real mode code for a bootloader for an OS course once, and I have designed and implemented some toy 8 bit CPUs which used segmentation to have more than 256 bytes of RAM, so I do have some experience with it)

flohofwoe 3y ago
Ah right, I totally misread segmentation as fragmentation, sorry. IMHO a more flexible segmentation system (exposed as base-pointer plus offset) wouldn't actually be bad if properly supported by high level languages. You could treat the base pointer as 'private knowledge' inside a system and only hand out the offset as a 'public handle'. To access a specific address you need both the private base pointer and public offset handle, and the base pointer could also move around without invalidating the offset handles in the wild. Of course all this can be done purely in software too already.