Memory management question

[Malcolm]

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

No, but they are heavily-used library functions, so you can assume a fairly
reasonable performance.

In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

The point is that in standard C you write

void killhugestructure(HUGE *h)
{
int i;

for(i=0;i<100000;i++)
free(h->ptr);
}

We know that this is a potential performance drag. (We might want to
optimise by consoloidating some of the pointers).

With garbage collection, the free()s just happen. Unless you know what is
going on, you might not realise that performance is going to take a hit.

 

[jacob navia]

Nothing in the language tells you how long malloc calls take.
Free can be longer sometimes if free() consolidates some memory.

No, but they are heavily-used library functions, so you can assume a fairly
reasonable performance.

In the long run both things (malloc/free) and the gc take the same
time. The time you spend doing free() must be counted too, as
well as the time you pass in the debugger.

The point is that in standard C you write

void killhugestructure(HUGE *h)
{
int i;

for(i=0;i<100000;i++)
free(h->ptr);
}

We know that this is a potential performance drag. (We might want to
optimise by consoloidating some of the pointers).

With garbage collection, the free()s just happen. Unless you know what is
going on, you might not realise that performance is going to take a hit.

When the next gc happens (when you call GC_malloc()) it will not take longer
than any other gc. That huge structure will be freed because no pointers to it
are valid. It just is enough to set h to NULL. This is an example of how
gc can be faster than a huge series of calls to free.

 

[Severian]

Of course, this is my own attitude to taking out the garbage. If
I postpone it, maybe something furry will come along and eat it
and save me the trouble. But the furry friend may also leave
a mess behind, and then my wife yells at me. :-[

The technique works fairly well with greasy pans and cats.

Works well with cat litter and dogs, too.

- Sev

 

[Serve La]

Of course, this is my own attitude to taking out the garbage. If
I postpone it, maybe something furry will come along and eat it
and save me the trouble. But the furry friend may also leave
a mess behind, and then my wife yells at me. :-[

But it's most C programmer's experience that when a program grows, the house
will get littered with little pieces of garbage without a furry friend
coming along. And then somebody decides to hang the house in a web
application.......

 

[Irrwahn Grausewitz]

So the future GC_malloc call is the one that is slowed. We can
(on most systems) get the same effect by simply not calling free
at all, and depending on the system doing the work at program
exit. At that time we can be pretty sure nothing critical is
going on, and the system can usually free everything bodily much
faster than individual free calls. With virtual memory this
actually has a fairly good chance of working, at least for a
while.

Barring such a ridiculous resolution, the point is that the work
still has to be done.

In addition to jacob's reply: in special cases, namely RealTime
applications, it's a somewhat common practice to allocate (most
of) the memory you need at program startup, so your running
process will not slow down indeterminately on later memory
(de)allocations. And a *real* RT OS knows nothing about
"virtual memory" or "swapping" or the like...

Sometimes, a ridiculous resolution is *the* solution to a given
problem.

Irrwahn.

 

[Irrwahn Grausewitz]

In addition to jacob's reply: in special cases, namely RealTime
applications, it's a somewhat common practice to allocate (most
of) the memory you need at program startup, so your running
process will not slow down indeterminately on later memory
(de)allocations. And a *real* RT OS knows nothing about
"virtual memory" or "swapping" or the like...

I received a nice rant (by email, accidentely) that makes me
clearify that with the above I didn't want to suggest that:

- Real Time applications and Real Time OS
are one and the same thing.

- You need an RTOS to write a RT Application.

- RTOSs are just for embedded systems.

- All RTOSs know nothing about virtual memory and swapping etc.

Wonder why I didn't get flamed on that slushy posting.

Thanks to Jason B.

Irrwahn

 

[Paul Hsieh]

I'd like to know who is responsible of memory recycling [...]

Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.
For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.

 

[Irrwahn Grausewitz]

(e-mail address removed) (Paul Hsieh) wrote in

I'd like to know who is responsible of memory recycling [...]

Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

Oh dear, didn't you read all the other's replies to his post?
BTW, there aren't things like 'new' or 'delete' or
'constructors' or 'destructors' in C!

[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.

For every heap allocation algorithm, there exists some sequence of
malloc's and free's that will arbitrarily fragment the heap.

As far as there's a heap at all... (C does not know about
heaps - the word isn't even mentioned in the standard).

MicroQuill's smartheap, and Windows both have handle based memory
allocations that allow for memory to shuffle and thus not fragment.
However, handle based memory allocation can be tedious/annoying to
deal with.

And C doesn't know any of these...

Sorry, I don't want to be rude, but why, for f-words sake,
did you post this reply, presumably ignoring the fact that
there's a charter AND a faq for this NG??? (Both of 'em are
worth reading, trust me, I'm a musician

Irrwahn

 

[Irrwahn Grausewitz]

This newsgroup has no charter, so I'm curious to discover how you managed to
read it.

Arrgh. Apologies.
Mixing up words, groups, people, phone numbers, toothpaste,
shaving foam, ... all together.
Today's not my day I guess; maybe too less beer yesterday
.... or maybe beginng Alzheimer 8-O

Erm, what did I say?

#include <stdlib.h>

char *retrieve_clc_charter( void )
{
return (char *) NULL;
}

int main( void )
{
if ( retrieve_clc_charter() == (char *) NULL )
return EXIT_FAILURE;
return EXIT_SUCCESS;
}

Irrwahn.

 

[CBFalconer]

Arrgh. Apologies.
Mixing up words, groups, people, phone numbers, toothpaste,
shaving foam, ... all together.
Today's not my day I guess; maybe too less beer yesterday
... or maybe beginng Alzheimer 8-O

Erm, what did I say?

#include <stdlib.h>

char *retrieve_clc_charter( void )
{
return (char *) NULL; ^^^^^^^^
}

int main( void )
{
if ( retrieve_clc_charter() == (char *) NULL )

^^^^^^^^

return EXIT_FAILURE;
return EXIT_SUCCESS;
}

The casts are unnecessary, and could conceivably hide errors.

 

[Irrwahn Grausewitz]

The casts are unnecessary, and could conceivably hide errors.

OK, this time I'll get it right:

////////////////////////////////////////////
// prog's purpose: retrieve c.l.c charter

#include <stdlib.h>

int main( void )
{
return EXIT_FAILURE;
}
////////////////////////////////////////////

And it's even shorter now.

 

[Paul Hsieh]

(e-mail address removed) (Paul Hsieh) wrote in

I'd like to know who is responsible of memory recycling [...]

Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

Oh dear, didn't you read all the other's replies to his post?

Yes I did. I noticed that none answered the real question of the
author, which is precisely *WHY* I chimed in. Why let this newsgroups
pervasive pedanticness ruin everyone's day?

BTW, there aren't things like 'new' or 'delete' or 'constructors'
or 'destructors' in C!

First of all, the concept of "constructor" and "destructors" are not
unique to C++. The bstring library (http://bstring.sf.net ) has them,
even in the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for. Saying C
doesn't have constructors or destructors is like saying it doesn't
have bubble sort.

Second of all, the the analogy between malloc/free and new/delete is
obvious. For someone interested in the knowlege of both it doesn't
make sense to state something about one and leave out the information
for the other.

[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.

Yes. And pointing this out has no value to anyone. Let alone
repeating it multiple times.

As far as there's a heap at all... (C does not know about
heaps - the word isn't even mentioned in the standard).

He is not asking questions about the standard. And this is not
comp.std.c. So what relevance does this useless observation have to
anything?

And C doesn't know any of these...

Sorry, I don't want to be rude, but why, for f-words sake,
did you post this reply, presumably ignoring the fact that
there's a charter AND a faq for this NG???

Have you read all the EULAs for all the software you've installed?
Are you a moderator for this newsgroup? Do you think every post in
comp.lang.c follows the charter? Do you think there is any value to
this charter? Do you think the many other posts which did nothing
more than rip into the OP for not following this newsgroups valueless
charter is useful?

So why did I do it? Because I decided not to be a *PRICK*.

[...] (Both of 'em are worth reading, trust me, I'm a musician

Unlikely. I can get a sense of what the charter is from the kind of
crap the regulars post here. That's like asking me to read the
Unibomber's Manifesto to have a more detailed understanding of why he
mailed bombs to people.

 

[goose]

(e-mail address removed) (Paul Hsieh) wrote in

(e-mail address removed) (sbayeta) wrote:
I'd like to know who is responsible of memory recycling [...]

Well, if you call malloc, you must call free, if you call new you must
call delete, if you have a constructor you must have a corresponding
destructor.

Oh dear, didn't you read all the other's replies to his post?

Yes I did. I noticed that none answered the real question of the
author, which is precisely *WHY* I chimed in. Why let this newsgroups
pervasive pedanticness ruin everyone's day?

<even more pervasive pedanticness>
istr that there was *at* *least* one post that answered the above
OP question.

First of all, the concept of "constructor" and "destructors" are not
unique to C++.

no, they aren't.

The bstring library (http://bstring.sf.net ) has them,
even in the C interface, for example. They are a programming concept,
as much as a mechanism that C++ has built-in support for. Saying C
doesn't have constructors or destructors is like saying it doesn't
have bubble sort.

it *doesn't* have bubble sort. it *does* have quicksort though.

[...] and defragmentation in a C/C++ program,

C/C++ does not provide any provisions for any serious defragmentation.

There's no C/C++ language, as others already pointed out.

Yes.

I agree.

And pointing this out has no value to anyone.

I disagree. Programmers should know that C and C++ are different
languages. There is value in this, as in the next time I have to
maintain "C" code which does casting on /malloc/ just to shut the
compiler up, I'll know that
a) the programmer hasn't the faintest clue that C and C++ are
different languages with occasionally different rules.
b) no one bothered to mention a) to him.

Let alone
repeating it multiple times.

it may be multiple to you, it may be the first time that the
OP has heard it.

He is not asking questions about the standard. And this is not
comp.std.c. So what relevance does this useless observation have to
anything?

I suppose that, in the interest of raising the general cluefullness
of the OP, it might be wise to point out that "heap" is not a std-c
concept. as a matter of fact, it might have been best for the
person who said "heap is not std" to have introduced the concept
of static and autmatic variable storage.


charter ?????

Have you read all the EULAs for all the software you've installed?
Are you a moderator for this newsgroup? Do you think every post in
comp.lang.c follows the charter?

what charter ?

Do you think there is any value to
this charter? Do you think the many other posts which did nothing
more than rip into the OP for not following this newsgroups valueless
charter is useful?

do you possibly think that misinformation is in the best interests
of the OP ? especially as his question was answered on-topic by someone
else ?

So why did I do it? Because I decided not to be a *PRICK*.

thats a good enough reason.

[...] (Both of 'em are worth reading, trust me, I'm a musician

Unlikely. I can get a sense of what the charter is from the kind of
crap the regulars post here.

you mean the kind of crap that tosses people a clue when they ask
for it ?

telling learners all about the "heap" in C does nothing for their
knowledge.

That's like asking me to read the
Unibomber's Manifesto to have a more detailed understanding of why he
mailed bombs to people.

what a wierd analogy ...

hth
goose,

 

[Alex]

(e-mail address removed) (Paul Hsieh) wrote in message news:<[email protected]>...

no, they aren't.

it *doesn't* have bubble sort. it *does* have quicksort though.

No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Alex

 

[Alex]

OK, this time I'll get it right:

////////////////////////////////////////////
// prog's purpose: retrieve c.l.c charter

#include <stdlib.h>

int main( void )
{
return EXIT_FAILURE;
}
////////////////////////////////////////////

Syntax error in C89

Alex

 

[Alex]

Typical?!?! I'm confused. A common representation for doubly linked
lists is to wrap the tail back to the top, so that you can quickly
reach either the head or the tail. If you simply drop the reference

<snip>

You are thinking of doubly linked circular lists.

Alex

 

[Serve La]

No, it doesn't. It has a 'qsort', which is not required by the
standard to utilize the 'quicksort' algorithm.

Why isn't there a bsort yet in the stdlib by the way? It's faster for small
collections and you don't have to reinvent the wheel. There could be lots of
other useful algorithms in there.

 

[Alex]

Why isn't there a bsort yet in the stdlib by the way? It's faster for small
collections and you don't have to reinvent the wheel. There could be lots of
other useful algorithms in there.

The point of my post was that "standard C does not mandate/endorse
the use of any specific algorithm". You are told that 'qsort' will
sort things, nothing else is guaranteed. Don't hold your breath for
the C equivalent of STL

Alex

 

[Dave Vandervies]

On 16 Aug 2003 02:03:02 GMT,


So it's essentially some reference counting scheme, right? I guess I'll
just stick with ref counting. Accomplishes the same thing, introduces very
little overhead (a dozen or two extra lines of code, maybe), and is
fully under my control.

struct double_linked_list_node
{
double_linked_list_node *prev,*next;
void *data;
};


dave
(Had to poke the sigmonster with a pointy stick a few times to get this one)

 

[Daniel Haude]

On Tue, 19 Aug 2003 18:44:33 +0000 (UTC),

struct double_linked_list_node
{
double_linked_list_node *prev,*next;
void *data;
};

Dave, if this is meant to be related to my post in any way whatsoever, I
fail to see that relation.

--Daniel