«

Hi,
I'd like to know who is responsible of memory recycling and
defragmentation in a C/C++ program, assuming all the memory
allocation/deallocation is done using malloc/free or new/delete.

Thanks

>I'd like to know who is responsible of memory recycling and
>defragmentation in a C/C++ program, assuming all the memory
>allocation/deallocation is done using malloc/free or new/delete.

The Internal Revenue Service. And they'll bill you for it.
But they may have subcontracted the job out to Bill Gates.

There is no language C/C++.

If the above wasn't the answer you wanted, what kind of answer
did you expect?

Gordon L. Burditt

"Mark A. Odell" <> wrote in message
news:Xns93D8973EFDD1FiiiCopyrightMarkOdelliii@130. 133.1.4...
> (sbayeta) wrote in
> news: om:
>
> > Hi,
> > I'd like to know who is responsible of memory recycling and
> > defragmentation in a C/C++ program, assuming all the memory
> > allocation/deallocation is done using malloc/free or new/delete.
>
> There is no C/C++ language. There is C which we discuss here. So from a C
> point of view there is no automatic memory recycling.

Wrong.

If I write:
int fn(void) {
char *a = malloc(100);
free(a);
return 0;
}

I expect that a reasonable implementation recycles the memory the best it can and my memory
consumption doesn't increase exponentially, sorry. I suppose that if I free a pointer, the memory
will be RECYCLED by the malloc/free system and the total memory consumption will not increase.

Of course I know that many implementations of malloc/free do not actually return the RAM to the OS
but recycle it for new requests. This is also a recycling strategy, sometimes more efficient
sometimes not.

But to say that there is no recycling in the malloc/free cycle (pun intended) is WRONG. If there was
no recycling why would we bother to call free() ?????


> You malloc() the
> memory and you must free it properly when done with it.

Yes. To be able to recycle it of course!

> If this
> process fragments memory over time, it's too bad as C does not do any
> garbage collection.

I would be surprised that the algorithms (known for decades) to avoid fragmentation wouldn't have
gotten into many malloc() implementations. They are quite sophisticated beasts. Of course it depends
of the quality of the run-time library, but most of them are very good quality stuff. Gcc for
instance has a quite good library.

Look Mark. There was recently a discussion (that I started, provocatively as a "spam" message
about the GC.
Now this question touches the same thema again, and you feel that the wrong party line is
insinuating somewhere.

And you loose control Mark. You say nonsense. How can you imagine that there is no recycling in C? I
mean those are the very basics.

jacob

"sbayeta" <> wrote in message
news: om...
> Hi,
> I'd like to know who is responsible of memory recycling and
> defragmentation in a C/C++ program, assuming all the memory
> allocation/deallocation is done using malloc/free or new/delete.
>
> Thanks

In C, memory recycling is done by the malloc/free system.
The malloc function allocates a new pointer, and free, releases it.

It is up to the implementation to recycle the memory, and many of
them have built sophisticated systems to avoid fragmentation, check
memory leaks, etc. Others aren't so good, sometimes they are slow and
may have bugs.

This system is very modular and can be easily replaced by your own
functions or another, non standard allocator.

But let's not start that discussion again

jacob

"jacob navia" <> wrote in
news:bhjdml$tvi$:

>> > I'd like to know who is responsible of memory recycling and
>> > defragmentation in a C/C++ program, assuming all the memory
>> > allocation/deallocation is done using malloc/free or new/delete.
>>
>> There is no C/C++ language. There is C which we discuss here. So from a
>> C point of view there is no automatic memory recycling.
>
> Wrong.
>
> If I write:
> int fn(void) {
> char *a = malloc(100);
> free(a);
> return 0;
> }
>
> I expect that a reasonable implementation recycles the memory the best
> it can and my memory consumption doesn't increase exponentially, sorry.

You've already killed your argument by saying a "reasonable
implementation" since that has nothing to do with what ISO C says. ISO C
doesn't say what an implementation, reasonable or otherwise must do with
free()'d memory.

> I suppose that if I free a pointer, the memory will be RECYCLED by the
> malloc/free system and the total memory consumption will not increase.

No, it just goes back into the available memory pool for subsequent
malloc's.

> Of course I know that many implementations of malloc/free do not
> actually return the RAM to the OS but recycle it for new requests. This
> is also a recycling strategy, sometimes more efficient sometimes not.
>
> But to say that there is no recycling in the malloc/free cycle (pun
> intended) is WRONG. If there was no recycling why would we bother to
> call free() ?????

Oh it goes back into the free list but it doesn't mean that you won't
fragment memory over time.

>> If this
>> process fragments memory over time, it's too bad as C does not do any
>> garbage collection.
>
> I would be surprised that the algorithms (known for decades) to avoid
> fragmentation wouldn't have gotten into many malloc() implementations.

Again with the implementation, where in the ISO C spec. does it say
malloc/free must use power of two allocators or any such thing?

> They are quite sophisticated beasts. Of course it depends of the quality
> of the run-time library, but most of them are very good quality stuff.
> Gcc for instance has a quite good library.

All off-topic platform-specific then.

> Look Mark. There was recently a discussion (that I started,
> provocatively as a "spam" message about the GC.
> Now this question touches the same thema again, and you feel that the
> wrong party line is insinuating somewhere.
>
> And you loose control Mark. You say nonsense. How can you imagine that
> there is no recycling in C? I mean those are the very basics.

I've never actually seen such a term in the pages of the spec. I've read.
Dan? Comment?

--
- Mark ->
--

"jacob navia" <> wrote in
news:bhjert$gae$:

>> I'd like to know who is responsible of memory recycling and
>> defragmentation in a C/C++ program, assuming all the memory
>> allocation/deallocation is done using malloc/free or new/delete.
>>
>> Thanks
>
> In C, memory recycling is done by the malloc/free system.
> The malloc function allocates a new pointer, and free, releases it.

Correct.

> It is up to the implementation to recycle the memory, and many of
> them have built sophisticated systems to avoid fragmentation, check
> memory leaks, etc. Others aren't so good, sometimes they are slow and
> may have bugs.

Correct, it's up to the *implementation* and is *not* dictated by the C
language thus do *not* depend on malloc/free to avoid fragmentation.

--
- Mark ->
--

"jacob navia" <> wrote in
<bhjdml$tvi$>:

>
>"Mark A. Odell" <> wrote in message
>news:Xns93D8973EFDD1FiiiCopyrightMarkOdelliii@130 .133.1.4...
>> (sbayeta) wrote in
>> news: om:
>>
>> > Hi,
>> > I'd like to know who is responsible of memory recycling and
>> > defragmentation in a C/C++ program, assuming all the memory
>> > allocation/deallocation is done using malloc/free or new/delete.
>>
>> There is no C/C++ language. There is C which we discuss here. So from a C
>> point of view there is no automatic memory recycling.
>
>Wrong.
So, if automatic memory recycling is a built in feature of
standardized C, what was this "Garbage Collection in C" thread
good for then?

>
>If I write:
> int fn(void) {
> char *a = malloc(100);
> free(a);
> return 0;
> }
>
>I expect that a reasonable implementation recycles the memory the best it can and my memory
>consumption doesn't increase exponentially, sorry. I suppose that if I free a pointer, the memory
>will be RECYCLED by the malloc/free system and the total memory consumption will not increase.
Maybe. Maybe not. You're expexting, guessing, supposing. What if
I'm just about to finish a conforming C implementation that
physically burns free()'d memory for security reasons? Is this
impossible?

[OT]
And please, please cut down your line length, your posts are
messing up my newsreader...

0 1 2 3 4 5 6
01234567890123456789012345678901234567890123456789 01234567890123456789
[/OT]

>
>Of course I know that many implementations of malloc/free do not actually return the RAM to the OS
>but recycle it for new requests. This is also a recycling strategy, sometimes more efficient
>sometimes not.
So, who is responsible for reclaiming free()'d memory then?

>
>But to say that there is no recycling in the malloc/free cycle (pun intended) is WRONG. If there was
>no recycling why would we bother to call free() ?????
To let the implementation do whatever it does with free()'d
memory...

>
>
>> You malloc() the
>> memory and you must free it properly when done with it.
>
>Yes. To be able to recycle it of course!
See above. Maybe it's recycled for further use. Maybe not.
(Whereas you're right in that *probably* *most* implementations
will do so.)

>
>> If this
>> process fragments memory over time, it's too bad as C does not do any
>> garbage collection.
>
>I would be surprised that the algorithms (known for decades) to avoid fragmentation wouldn't have
>gotten into many malloc() implementations. They are quite sophisticated beasts. Of course it depends
>of the quality of the run-time library, but most of them are very good quality stuff. Gcc for
>instance has a quite good library.
Right, *many implementations* will do so. Got the point?

>
>Look Mark. There was recently a discussion (that I started, provocatively as a "spam" message
>about the GC.
>Now this question touches the same thema again, and you feel that the wrong party line is
>insinuating somewhere.
Starting it all over again... *g*

>
>And you loose control Mark. You say nonsense. How can you imagine that there is no recycling in C? I
>mean those are the very basics.
IMHO Mark is perfectly right. You are the one who's generalizing
the behaviour of some implementations to be the one and only way
to do things. Basically, I *can* imagine C without memory
recycling. ( Maybe there's a lack of imaginational potential on
your side? *g* )


Ooooops, I just stumbled over this (from the N843 draft):
-----
7.20.3.2 [...] [#2] The free function causes the space pointed
to by ptr to be deallocated, that is, made available for
further allocation.
-----

Maybe I was totally wrong

That's why I call for the experts now - please help.


Irrwahn

--
If you can see it and it’s there - it’s real.
If you can’t see it, but it’s there - it’s transparent.
If you can see it but it isn’t there - it’s virtual.
If you can’t see it and it isn’t there - it’s gone.

>So, if automatic memory recycling is a built in feature of
>standardized C, what was this "Garbage Collection in C" thread
>good for then?

Automatic memory recycling is re-using freed memory.
Garbage collection is re-using non-freed memory when (hopefully)
it is no longer in use.

>Maybe. Maybe not. You're expexting, guessing, supposing. What if
>I'm just about to finish a conforming C implementation that
>physically burns free()'d memory for security reasons? Is this
>impossible?

The clause in ANSI C about making the memory available for later
allocation would seem to prohibit this. Some claim it also
prohibits releasing it back to the OS if there is any possibility
that the OS would give it to some other process and refuse
a request to get it back to the one that released it. The really
pedantic ones insist that it has to be willing to give back
the *SAME* *PHYSICAL* *MEMORY* before it can claim it ran out.

>Ooooops, I just stumbled over this (from the N843 draft):
> -----
> 7.20.3.2 [...] [#2] The free function causes the space pointed
> to by ptr to be deallocated, that is, made available for
> further allocation.
> -----

>So, who is responsible for reclaiming free()'d memory then?

There is no WHO in this discussion. malloc()/free() is not alive.
ANSI C is not alive. Laidlaw of Benbrook has no contract for
cyberspace. I guess it defaults to Bill Gates or the IRS.

As far as defragmentation goes, it is nearly impossible in C to
move around *ALLOCATED* pieces of memory without breaking something.
This is made particularly a problem by the fact that pointers (which
would require moving if you move the data they point at, but only
if they really are intended as pointers) can be hidden in files or
encrypted in memory.

Gordon L. Burditt

(Gordon Burditt) wrote in
<bhjhuu$>:

<BIG SNIP>
>>So, who is responsible for reclaiming free()'d memory then?
>
>There is no WHO in this discussion. malloc()/free() is not alive.
>ANSI C is not alive.
Sorry for my broken english.

Thank you very much for clearing things up.


--
If you can see it and it’s there - it’s real.
If you can’t see it, but it’s there - it’s transparent.
If you can see it but it isn’t there - it’s virtual.
If you can’t see it and it isn’t there - it’s gone.

> You've already killed your argument by saying a "reasonable
> implementation" since that has nothing to do with what ISO C says. ISO C
> doesn't say what an implementation, reasonable or otherwise must do with
> free()'d memory.

The standard says
(I quote page 312, free() definition)

The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation.

end quote

Next allocations will recycle the memory freed!
>
> > I suppose that if I free a pointer, the memory will be RECYCLED by the
> > malloc/free system and the total memory consumption will not increase.
>
> No, it just goes back into the available memory pool for subsequent
> malloc's.

And this is not recycling Mark?
I mean what are you trying to achieve? Confusion?

jacob