Friday 3 November 2017

c++ - Address of start block storage

itemprop="text">


The
allocation function attempts to allocate the requested amount of

storage.
If it is successful, it shall return the address of the start of
a
block of storage whose length in bytes shall be at
least
as large as

the requested
size.




What does
that constraint mean? Could you get an example it
violates?



It seems, my question is
unclear.
UPD:
Why "at least"? What is the point of allocation more
than requested size? Could you get suitable example?



Answer




The allowance for allocating "more than
required" is there to
allow:





  1. Good
    alignment of the next block of data.

  2. Reduce restrictions
    on what platforms are able to run code compiled from C and
    C++.

  3. Flexibility in the design of the memory allocation
    functionality.



An
example of point one is:



 char *p1
= new char[1];

int *p2 = new
int[1];


If we allocate
exactly 1 byte at address 0x1000 for the first allocation, and follow that exactly with
a second allocation of 4 bytes for an int, the int will start
at address 0x1001. This is "valid" on some architectures, but often leads to a "slower
load of the value", on other architectures it will directly lead to a crash, because an
int is not accessible on an address that isn't an even multiple
of 4. Since the underlying architecture of new doesn't actually
know what the memory is eventually going to be used for, it's best to allocate it at
"the highest alignment", which in most architectures means 8 or 16 bytes. (If the memory
is used for example to store SSE data, it will need an alignment of 16
bytes)



The second case would be where "pointers
can only point to whole blocks of 32-bit words". There have been architectures like that
in the past. In this case, even if we ignore the above problem with alignment, the
memory location specified by a generic pointer is two parts, one for the actual address,
and one for the "which byte within that word". In the memory allocator, since typical
allocations are much larger than a single byte, we decide to only use the "full word"
pointer, so all allocations are by design always rounded up to whole words.



The third case, for example, would be to use a
"pre-sized block" allocator. Some real-time OS's for example will have a fixed number of
predefined sizes that they allocate - for example 16, 32, 64, 256, 1024, 16384, 65536,
1M, 16M bytes. Allocations are then rounded up to the nearest equal or larger size, so
an allocation for 257 bytes would be allocated from the 1024 size. The idea here is to
a) provide fast allocation, by keeping track of free blocks in each size, rather than
the traditional model of having a large number of blocks in any size to search through
to see if there is a big enough block. It also helps against fragmentation (when lots of
memory is "free", but the wrong size, so can't be used - for example, if run a loop
until the system is out of memory that allocates blocks of 64 bytes, then free every
other, and try to allocate a 128 byte block, there is not a single 128 byte block free,
because ALL of the memory is carved up into little 64-byte sections).


No comments:

Post a Comment

php - file_get_contents shows unexpected output while reading a file

I want to output an inline jpg image as a base64 encoded string, however when I do this : $contents = file_get_contents($filename); print &q...