How delete works!

Hi freinds,
How delete operator comes to know , how much memory it has to
deallocate?

Neo

Neo wrote:
[color=blue]
> Hi freinds,
> How delete operator comes to know , how much memory it has to
> deallocate?[/color]

Any implementation is free to devise its own magic. Possible approaches
include:

a) allocate a little more and store the size within the allocated region.
b) store the size within the pointer variable.
c) use the low-order bits of a pointer to keep track of the size (only
supports very few different sizes and need some overhead for
dereferencing).
d) use different chunks of memory to allocate objects of different sizes.
This way, the location of an object allows you to tell its size.


Best

Kai-Uwe Bux

Neo wrote:[color=blue]
> How delete operator comes to know , how much memory it has to
> deallocate?[/color]

It depends on the implementation. Memory allocation systems in general
can be quite subtle and complex, so there is no easy answer. Generally
speaking, though, when memory is allocated a small amount of
"housekeeping data" is used along with it (note I did not say it is
co-located with the allocated memory; it needn't be). The delete
operator has access to this data and uses it accordingly.

For example, one implementation would be a hash table mapping pointers
(addresses to the first byte of each allocated block of memory) to
sizes. The delete operation would look up the size based on the value
of its argument. This is only part of the picture, of course -- the
next question is, how does the new operator know what memory is
available to allocate when a request comes in for a (contiguous) block
of a particular size? There's a great deal of reading material
available on this topic; if you're interested, search the web, visit a
library, or patronize a bookseller such as Amazon.com*.

Luke

* ObDisclosure: I work there. Oh, and I guess I own some stock, or
will once it vests.

Hie,
Thanx for reply.Please see my comments...

a) allocate a little more and store the size within the allocated
region.
==> This seems to be okey.

b) store the size within the pointer variable.

==>If pointer variable is holding the sizeof object which is too big
then we are in truoble.See that is why we have virtual table pointers
placed inside the object and pointer dont really knows which type of
object we are pointing.

c) use the low-order bits of a pointer to keep track of the size (only

supports very few different sizes and need some overhead for
dereferencing).

==>same as disscussed in point (b)

d) use different chunks of memory to allocate objects of different
sizes.
This way, the location of an object allows you to tell its size.
==>can u be more precise on this? seems to be interesting ...


Neo




Kai-Uwe Bux wrote:[color=blue]
> Neo wrote:
>[color=green]
> > Hi freinds,
> > How delete operator comes to know , how much memory it has to
> > deallocate?[/color]
>
> Any implementation is free to devise its own magic. Possible approaches
> include:
>
> a) allocate a little more and store the size within the allocated region.
> b) store the size within the pointer variable.
> c) use the low-order bits of a pointer to keep track of the size (only
> supports very few different sizes and need some overhead for
> dereferencing).
> d) use different chunks of memory to allocate objects of different sizes.
> This way, the location of an object allows you to tell its size.
>
>
> Best
>
> Kai-Uwe Bux[/color]

Neo wrote:
[color=blue]
> Hie,
> Thanx for reply.Please see my comments...
>
> a) allocate a little more and store the size within the allocated
> region.
> ==> This seems to be okey.
>
> b) store the size within the pointer variable.
>
> ==>If pointer variable is holding the sizeof object which is too big
> then we are in truoble.See that is why we have virtual table pointers
> placed inside the object and pointer dont really knows which type of
> object we are pointing.[/color]

I am not following this. What do you mean by the "sizeof object" being "too
big". And what kind of trouble do you see. As far as I can tell, on a 32
bit architecture as 64bit pointer variable will happily hold the
information about position and length of any consecutive region of memory.
Of course, for accessing your would only need first 32 bits of that pointer
variable, however nothing in the standard prevents an implementation from
making sizeof(T*) bigger than you might expect.
[color=blue]
>
> c) use the low-order bits of a pointer to keep track of the size (only
>
> supports very few different sizes and need some overhead for
> dereferencing).
>
> ==>same as disscussed in point (b)[/color]

Same as in b): I do not see the objection.
[color=blue]
> d) use different chunks of memory to allocate objects of different
> sizes.
> This way, the location of an object allows you to tell its size.
> ==>can u be more precise on this? seems to be interesting ...[/color]

Well, your allocator has a pool for 4-byte objects another pool for 8-byte
objects, and so on. For instance, when asked to allocate the first 4-byte
object, the allocator asks the OS for 64KB. It now has a pointer to the
beginning of that chunk and uses that chunk to serve all requests for
4-byte allocation. Whenever you delete a pointer that points into this
chunk, the allocator can deduce that it points to a 4-byte object.


Best
[color=blue][color=green]
>> Neo wrote:
>>[color=darkred]
>> > Hi freinds,
>> > How delete operator comes to know , how much memory it has to
>> > deallocate?[/color]
>>
>> Any implementation is free to devise its own magic. Possible approaches
>> include:
>>
>> a) allocate a little more and store the size within the allocated region.
>> b) store the size within the pointer variable.
>> c) use the low-order bits of a pointer to keep track of the size (only
>> supports very few different sizes and need some overhead for
>> dereferencing).
>> d) use different chunks of memory to allocate objects of different sizes.
>> This way, the location of an object allows you to tell its size.[/color][/color]

Please do not needlessly attach a copy of the message. Folks in this news
group, including me, are very sensitive to quoting styles. The preferred
style here is to do as you did in the first part of your post: quote and
write your comments right below what they refer to.


Best

Kai-Uwe Bux

Hi
As you said we have 64 bit pointers..as far as I know for 32 bit
systems we have 32 bit sized pointers.If there are any 64 bit pointers
I really dont know about that. I am working with windows 2000 under
microsoft C++ compiler version 6.0.

for storing a size of (large)object , I need more bits from pointer
variable. So what if size is too large. As sizeof operator returns size
(size_t) is an unsigned integer. More the size more the bits I need !
Please let me know if there are any misunderstandings...
Also thanx for mentioning about message posting standards. This is my
first post and I am really happy that lot of good people are here
around !

Neo

On 2006-05-26 12:08, Neo wrote:[color=blue]
> Hi
> As you said we have 64 bit pointers..as far as I know for 32 bit
> systems we have 32 bit sized pointers.If there are any 64 bit pointers
> I really dont know about that. I am working with windows 2000 under
> microsoft C++ compiler version 6.0.[/color]

What Kai-Uwe Bux tried to say was that even though only 32 bits are
needed for a pointer (on a 32-bit machine) there is no rule (as far as I
know) that prevents an implementation from using more. So one could make
an implementation where pointers are 64 bits and uses half of them to
tell the size of the object the other half points to.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

Neo wrote:[color=blue]
> Hi freinds,
> How delete operator comes to know , how much memory it has to
> deallocate?
>
> Neo[/color]

Two cases: types with and without a virtual destructor.
If the type has a virtual destructor, delete will call that before
deallocating memory.
Now, since you cannot define a return type, the compiler might use a
(hidden)
return value to return that information. Another solution is to store
the size in a
vtable. There are even more variations, but all take advantage of the
fact that the
compiler has type information for this object, and it's easy to add
size to that type
information.

The case without a virtual destructor is easy. delete then gets a
pointer of exactly
the right type, not a base type. So if it gets a T*, it knows it has to
call T::~T and
then deallocate sizeof(T).

HTH,
Michiel Salters

In article <1148638085.431124.221190
@j73g2000cwa.googlegroups.com>, vikram.sutar@gmail.com
says...[color=blue]
> Hi
> As you said we have 64 bit pointers..as far as I know for 32 bit
> systems we have 32 bit sized pointers.If there are any 64 bit pointers
> I really dont know about that. I am working with windows 2000 under
> microsoft C++ compiler version 6.0.[/color]

Under Win32, you use only 32 bit of a pointer -- but the
processor (Intel/AMD x86) actually requires 48-bits. The
48 bits consists of a 16-bit segment and a 32-bit offset.
In Win32, the segments are fixed, and all you work with
are offsets.

Nonetheless, if somebody wanted to, they could perfectly
well use multiple segments. In that case, they create a
"descriptor" for a segment that specifies (among other
things) the maximum offset legal for that segment (i.e.
the size of the memory block it refers to). The usual
Win32 segments are all set to a size of 4 GB, but that's
not required in general -- under a different system, you
could set them to the actual sizes of the memory blocks
they referred to.
[color=blue]
> for storing a size of (large)object , I need more bits from pointer
> variable. So what if size is too large. As sizeof operator returns size
> (size_t) is an unsigned integer. More the size more the bits I need !
> Please let me know if there are any misunderstandings...[/color]

There are quite a few ways of getting around this
problem. One is outlined above -- associate some data
with the pointer, but don't make it part of the pointer
itself. Another is to limit your selection of sizes. For
example, many memory allocators round the size of any
allocation to the next larger power of 2. In this case,
you really don't need to store the size of the
allocation, but instead just the base 2 logarithm of the
size. For a 64-bit system, that means the maximum size
you need to store is 64 -- which only requires 6 bits.
Most 64-bit systems only really use around 48 bits (or
less) for actual addressing. That leaves 16 bits (or
more) in the pointer that can be used to hold other data,
such as sizes, types, etc.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Neo posted:
[color=blue]
> Hi freinds,
> How delete operator comes to know , how much memory it has to
> deallocate?
>
> Neo[/color]


God::Communicate::AskCompilerSpecificQuestion();


-Tomás