Do pointers returned by malloc/new have to be aligned?

This is a discussion on Do pointers returned by malloc/new have to be aligned? within the C++ Programming forums, part of the General Programming Boards category; Hi, I implemented my own memory management if form of own allocator functions which operate on my own data structures ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    Do pointers returned by malloc/new have to be aligned?

    Hi,

    I implemented my own memory management if form of own allocator functions which operate on my own data structures and on my own, pre-allocated memory buffer.

    This is my memory pool:

    Code:
    std::vector<unsigned char> pool(some_upper_size);
    
    void* my_alloc(size_t size)
    {
        reserve size un-allocated bytes inside pool on offset X;
        void* ret_val = &pool[0] + X;
        return ret_val;
       
    }
    Does ret_val need to be aligned to machine word boundaries (which should be size(int))?

    If I allocate a bunch of single unsigned chars using new, VC++ returns pointers every 32bit in release (every 64 bit in debug, but I guess it encodes error detection code into the heap space).

    Thank you in advance!

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    What alignment is needed depends mainly on the processor. And "needed" ranges from "if it's wrong you loose a bit of performance" to "if it's wrong, it doesn't work".

    Generally, it's considered a good idea to align to at least 8 bytes, preferably 16.

    In x86 (older processors) a cache-line is 32 bytes, so if you do not want to processors to have "false-sharing" [which is where two CPU's are not sharing the actual data, but data from the same cache-line is used by two different processors], then aligning to "a cache line" will reduce the problems with this.

    It is also good to avoid splitting blocks into TINY fragments, as that is most likely going to end up with a heap that contains a lot of 1-byte blocks that no one can use, which is another reason for having a minimum heap-block-size (e.g. 32 bytes).

    --
    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
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    The language requires that the returned pointer is "of suitable alignment for the largest supported type". Reality says that the alignment is either 8 (for doubles, and pointers on 64-bit) or 16 (so you can use it for SSE algorithms). Common sense says that it should most definitely not be less aligned than what the system default allocator returns.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Thank you both.

    I added alignment to 16 byte boundaries. But I must have overseen something.

    A library I use can take a custom allocator function. If it gets one, it uses only these to allocate memory. if no custom one is passed, it uses this default:

    Code:
    static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
      (void)ud;
      (void)osize;
      if (nsize == 0) {
        free(ptr);
        return NULL;
      }
      else
        return realloc(ptr, nsize);
    }
    I've tried different implementations of a custom function with less and less features. None of that worked (the library functions crashed due to memory access error after a time).

    Now I tried the very simplest version of a custom function I could come up with. It just allocs and returns the memory asked for. It doesn't care about freeing of memory, re-allocation, corruption checks, fragmentation or anything else.

    Code:
    void* LuaMemoryManager::alloc_impl_manual3( void* ptr, size_t osize, size_t nsize )
    {
    	if (nsize)
    	{
    		std::vector<unsigned char>* mem = new std::vector<unsigned char>(nsize);
                     //yes, it will leak. don't care for now
    
    		return &(*mem)[0]; //returned memory position should be aligned by new
    	}
    	return NULL;
    }
    The problems/crashes remains.
    I must do some fundamental error or understand some detail wrong. Any Ideas?
    Last edited by pheres; 03-24-2009 at 07:35 AM.

  5. #5
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    I forgot to move the memory in case of re-allocating. It is solved.

  6. #6
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,296
    Quote Originally Posted by pheres View Post
    Code:
    void* LuaMemoryManager::alloc_impl_manual3( void* ptr, size_t osize, size_t nsize )
    {
    	if (nsize)
    	{
    		std::vector<unsigned char>* mem = new std::vector<unsigned char>(nsize);
                     //yes, it will leak. don't care for now
    
    		return &(*mem)[0]; //returned memory position should be aligned by new
    	}
    	return NULL;
    }
    Don't just leak like that. From experience, it'll stay that way for about the next five years, upon which time it finally comes back to bite you and takes hours to track down. There's no reason for it to be a vector here at all. Why not just new up the right number of bytes straight off?!
    Also, you're probably supposed to take ptr and osize into acount instead of just ignoring them. Usually you'd multiple the last two values together.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Yes I know and in the real program it's implemented in a much better way (I hope), but I though the chances of getting the right tip is much higher if I develop and post the simplest possible solution. (the productive function with debugging code to mark and track correct handling of blocks is way bigger). Also it helped my to exclude other possible errors regarding free and re-use of blocks.

    Ok, in my case the simplest solution was to simple, because it ignored one of realloc's tasks - moving the memory to the new home
    Last edited by pheres; 03-24-2009 at 12:05 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Arrays, pointers and strings
    By Apropos in forum C++ Programming
    Replies: 12
    Last Post: 03-21-2005, 10:25 PM
  2. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 08:32 AM
  3. Pointers to function(function pointers)
    By abhishek_charli in forum C Programming
    Replies: 4
    Last Post: 06-23-2002, 01:24 AM
  4. Replies: 4
    Last Post: 09-12-2001, 02:05 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21