[vox-tech] lame question on memory allocation

[Jeff Newmiller]

On Tue, 21 Jan 2003, Tim Riley wrote:

> 
> 
> Peter Jay Salzman wrote:
> 
> > you'd think by now i'd know stuff like this.  i'm embarrased to have to
> > ask this, but here it goes.
> 
> Don't be -- memory management is complicated and gets more so
> everytime they improve the hardware. As a result, the vocabulary
> can get esoteric.
> 
> >
> >
> > i'm reading the man page for electric fence, and i'm not fully
> > understanding the sections on EF_ALIGNMENT and "WORD-ALIGNMENT AND
> > OVERRUN DETECTION".   i feel like i "almost" understand them.
> >
> > i think i understand the concept of memory page as being the minimum
> > chunk of memory the kernel handles internally (8192 bytes minimum
> > allocation of memory on x86) and alignment, but i guess i don't know
> > what a word is.
> >
> 
> More specifically, a page is a chunk of memory that the operating system
> (or hardware) copies to disk (swap space) when you run out of memory -- aka
> "page fault." To optimize this process, memory is allocated by the page.
> 
> >
> > for example, the man page says that malloc() may be required to return
> > word aligned memory pages, so in the diagram:
> >
> 
> This implies that malloc() may return more memory than you request.
> It might be that malloc( 1 ) gets you an entire page -- 4 or 8 K. However,
> subsequent malloc( 1 )s will just fill in the existing page. When it fills
> up you
> get a new page.
> 
> The gcc complier knows about page alignments and will allocate
> memory requested on the stack effeciently. So, whenever I need
> string space, I'll do: "char buffer[ 1024 ];" because I believe that
> "char buffer[ 1000 ];" gets me 1024 anyway.

a) malloc() affects heap memory, not stack memory.

b) Don't forget that malloc() is a library call that uses data structures
to keep track of allocated memory.  Some implementations reserve
some memory for allocated memory, while others simply take over
freed memory and ignore allocated memory.  An implementation that keeps
track of allocated memory will allocate more than you ask for, and use teh
extra for its own uses.

My point is that your "optimization" is rather implementation-specific...
it can backfire if the code is ported, yielding less efficient use of
memory by requiring two pages instead of one.  (If you don't mind some
platform dependencies in your search for performance, this may be par for
the course.)

> 
> >
> >          1 page allocated by malloc()
> > x       ------------
> > x+1     |          |
> > x+2     | 8192     |
> >         | bytes on |
> >         |   x86    |
> >         |          |
> >         ------------
> >
> > i guess that places a restriction on what "x" is, but because i don't
> > know what a word is, i don't know what that restriction is.
> >
> > what's a word?  :)
> >
> 
> A word is the minimum amount of addressable memory. So, if you
> declare "char c;" on the stack of a 386, even though you plan on storing
> only 8 bits, more bits are available. To figure out the word size, take
> the log based 2 of the constant UINT_MAX + 1 (in limits.h) -- probably
> it's 32.

Actually, the minimum amount of addressable memory is more commonly
referred to as a byte.  (Technically, the minimum amount of addressable
memory _large enough to represent any printable character in the "C"
locale_ is a byte... some architectures can address bits.)

A word is the natural unit of data that can be moved from memory to a
processor register. [1]  Most modern processors have data paths composed
of multiple bytes, and separate "enable" signals allow smaller units of
data than a "word" to be read or written.  This definition differs from
the x86 version, which is fixed by convention at 16 bits to support
upward software compatibility for certain compilers and assemblers.

It may be inefficient to move a "word" around that is not stored beginning
with the first addressable byte in the data bus.  Part of the word has to
be read in one bus operation, and the rest in a second bus
operation.  This is strongly discouraged on some architectures, to the
point that they won't support such memory accesses directly, preferring
instead to raise an exception (interrupt).  Even if it is allowed, it
represents a performance hit that can be avoided if data is laid out
properly.

> 
> >
> > or does it mean that there's a restriction on *size* of the page and not
> > the starting point?
> >
> 
> The page size is set by the hardware, and the Linux kernel manages paging
> transparently. I'm surprised to hear about an application that is forcing
> you
> to make decisions about memory alignment.

It isn't forcing the issue... simply providing it as an option to aid in
identifying misaligned data accesses that could be a portability or
performance problem.


[1] http://WhatIs.techtarget.com/definition/0,,sid9_gci498438,00.html

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------