Thread: Allocation Granularity and fragmentation

  1. #1
    Registered User
    Join Date
    May 2007
    Posts
    41

    Allocation Granularity and fragmentation

    Hello

    in Windows each process has its virtual address space to allocate dynamic memory.
    To allocate a region of the virtual address space I use VirtualAlloc.
    the size of allocated regions is always a multiple of the page size.
    And every region I alloc starts on a 64k boundary...so every pointer returned by sequential calls to VirtualAlloc should be a multiple of 64 * 1024 (64k).
    Let's say that in my system the page size is 4k and the allocation granularity is 64k.

    I call VirtualAlloc to allocate 2 pages (8k). The pointer it returns is a multiple of 64k.
    Then I call VirtualAlloc to allocate other 2 pages (on another region). The pointer is a multiple of 64k so it should be the pointer it returned in the first call + 64k. Right?

    then I can't use the pages that aren't allocated from the first pointer to the second pointer?

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I believe all you state is correct. VirtualAlloc isn't intended for "small" allocations, and if you want to use it that way, you're probably going to have to build your own little allocation/free functions that split a large (multiple of 64K) section into smaller portions.

    Or use either malloc, HeapAlloc(), or the new operator (C++ only), with the corresponding free functions.

    As so often, this is a "How do I loosen a wheel-nut" question, when you actually want to understand how to fix a puncture/flat tyre on a car - to correctly advice you, we need to know more about what you are actually using VirtualAlloc to do, and what you are trying to achieve on in the big picture.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    VirtualAlloc is great in that you can allocate any given virtual address in your virtual memory space. Terrific for things such as expanding arrays when you simply allocate memory beyond the end of the array.
    However, if you don't really need to reserve or commit a specific address within the virtual memory space, I dare say it's better to use new/delete (C++) or mallc/free (C).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Registered User
    Join Date
    May 2007
    Posts
    41
    ok...so VirtualAlloc is intended for large buffers...
    Anyway why do a region must start on a 64k boundary? what's the reason?

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by ZeroMemory View Post
    ok...so VirtualAlloc is intended for large buffers...
    Anyway why do a region must start on a 64k boundary? what's the reason?
    Probably a fairly arbitrary decision, 64K is big enough that you can track the number of allocations in a 4GB memory range with a relatively small set of references, but at the same time small enough that you don't waste TOO much memory when allocating small blocks.

    That's just a guess, I have no inside info on why MS decided to do things this way - there may be all sorts of different reasons why they did this. The important part, I think, is that the granularity is 64K.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed