4 ms·
> Windows is full of these arbitrary constants, like the 32kiB paging chunk for instance. I assume you’re referring to the 64KiB allocation granularity? That’s
by dblohm7 3y ago
> Windows is full of these arbitrary constants, like the 32kiB paging chunk for instance.
I assume you’re referring to the 64KiB allocation granularity? That’s actually not at all arbitrary: https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42223 https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42...
- amluto 3y agoHuh, I never knew that particular detail, and I’ve played with Windows quite a bit. But, with my modern OS developer hat on, I’d say it’s a bit lazy, not arbitrary. > So if allocation granularity were finer than 64KB, a DLL that got relocated in memory would require two fixups per relocatable address: one to the upper 16 bits and one to the lower 16 bits. … > Forcing memory allocations at 64KB granularity solves all these problems. It does, at the cost of silly limitations. A much nicer solution IMO would have been a way to ask for a 64kB aligned allocation for DLLs.
- brucedawson 3y agoWhat advantages would you get by being able to reserve memory with a finer than 64-KiB granularity? Especially with 64-bit Windows it seems quite unnecessary to have finer granularity. Am I missing something?
- amluto 3y ago64-bit is recent and 64kB granularity is ooooollllld. With 64 bits, my real objection is that it’s unnecessarily complicated. There’s some data structure that maps addresses to whatever is mapped at those addresses, and on Windows it also needs to track reserved memory, and it needs to do so at a different granularity. (For huge pages, additional granularities are needed.)
- jacobgorm 3y agoBy paging chunk I mean the amount of data that gets read in by a hard fault to disk.