Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Memory management question

Reply
Thread Tools

Memory management question

 
 
Mark A. Odell
Guest
Posts: n/a
 
      08-15-2003
"jacob navia" <(E-Mail Removed)> wrote in
news:bhjj2g$nv3$(E-Mail Removed):

>> 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.


Hmm... I should have continued by saying "except that the free'd memory
can now be malloc'd again".

> 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!


Okay I can't argue with that definition of recycling memory. I didn't mean
to imply that once freed you couldn't remalloc that same memory region
just that if you keep malloc'ing and free'ing different sized blocks of
memory you may fragment the memory such that you begin to fail large
malloc's.

>> > 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?


No, I just thought you were saying that C provides anti-framentation as
part of the language, which it does not.

--
- Mark ->
--
 
Reply With Quote
 
 
 
 
Gordon Burditt
Guest
Posts: n/a
 
      08-15-2003
>
>Look. I have an automatic drive in my car. I do not feel like changing gears.
>
>Many drivers I know though, like manually changing gears. They tell me about the
>"good driving" feeling they get when they do this manually.
>
>malloc/free require a manual interface. The driver needs to free each piece of
>memory at the right point and never make a mistake. Many of them tell that
>with a good discipline this is possible, and I must confess that before
>I used a gc
>I got through that too.
>
>But now, I prefer the automatic you see? No more free(). The gc does it for me.


But, to continue the analogy, sometimes the automatic transmission
does it wrong when you're towing a trailer (hiding pointers where
the gc can't find them). Either it ruins the engine (frees memory
that should NOT be free), or it slows down horribly (spends enormous
amounts of time looking for pointers where they aren't) and takes
24 hours to get home. And there's no practical way to fix this
without putting restrictions on how you drive.

Now what happens when a one of a generation of drivers who grew up
with automatic transmissions only need to tow a trailer?

Gordon L. Burditt
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      08-15-2003

"Gordon Burditt" <(E-Mail Removed)> wrote in message
news:bhjkif$(E-Mail Removed)...
> >

[snip]
>
> But, to continue the analogy, sometimes the automatic transmission
> does it wrong when you're towing a trailer (hiding pointers where
> the gc can't find them). Either it ruins the engine (frees memory
> that should NOT be free), or it slows down horribly (spends enormous
> amounts of time looking for pointers where they aren't) and takes
> 24 hours to get home. And there's no practical way to fix this
> without putting restrictions on how you drive.
>


Yes, but I can go farther because I am less tired you see?

Automatic driving requires less efforts from the driver and he/she
can drive longer distances!

For instance, I added the GC to the debugger/IDE of lcc-win32.

Because I do not have to write any code to cope for free() bugs or
problems, I used the saved time to improve the application itself.

I concentrated in the debugger itself, a *very* complex application.
Real time, with 3 threads running (debugger IDE, program under
debug, and debugger itself), with many complex specs to read the
debug info, messages that must be formated at each break, etc etc!

Now, I know that I can allocate a buffer whenever I need one, and
that I can pass it around without caring where I will free the stuff!!!

Debugging the debugger is difficult. Without the GC I would have been
slowed down by all those accounting chores and would have had less
time to try to improve it.

Besides, the crashes due to messing around with free would be
inacceptable. A debugger crashing, what a nightmare

I spoke once with a TAXI driver (!!!) with manual driving. I told him:

Look, it doesn't hurt your hand at the end of the day?
You do not get feed up?

He admitted that it hurt a bit, but then he started telling me all
the bad things that stupid automatic drivers
do, that they do not know their vehicle etc etc.

I said nothing, payed and got out. There must be all kinds of people to
fill this world. It is his opinion. I respect it.

jacob



 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      08-15-2003

"jacob navia" <(E-Mail Removed)> wrote in message
>
> Yes, but I can go farther because I am less tired you see?
>
> Automatic driving requires less efforts from the driver and he/she
> can drive longer distances!
>

There is a case for using a language with automatic garbage collection.
Modern C++ with the stl is one such language.

However that language isn't C. Part of the philosophy of C is that every
statement, apart from a function call, compiles to only a few machine code
instructions. Therefore you can see where your cycles are going.

Automatic garbage collection breaks that design principle.


 
Reply With Quote
 
Severian
Guest
Posts: n/a
 
      08-15-2003
On Sat, 16 Aug 2003 00:02:21 +0100, "Malcolm"
<(E-Mail Removed)> wrote:

>
>"jacob navia" <(E-Mail Removed)> wrote in message
>>
>> Yes, but I can go farther because I am less tired you see?
>>
>> Automatic driving requires less efforts from the driver and he/she
>> can drive longer distances!
>>

>There is a case for using a language with automatic garbage collection.
>Modern C++ with the stl is one such language.
>
>However that language isn't C. Part of the philosophy of C is that every
>statement, apart from a function call, compiles to only a few machine code
>instructions. Therefore you can see where your cycles are going.
>
>Automatic garbage collection breaks that design principle.


In many situations, neither mechanism (std malloc, GC) is appropriate.
I've had to write my own memory management routines for several
applications because of malloc's deficiencies.

- Sev

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-15-2003

"Malcolm" <(E-Mail Removed)> wrote in message
news:bhjofn$dee$(E-Mail Removed)...
>
> However that language isn't C. Part of the philosophy of C is that every
> statement, apart from a function call, compiles to only a few machine code
> instructions. Therefore you can see where your cycles are going.
>
> Automatic garbage collection breaks that design principle.


No. When you call malloc() you can expect a GC. Very simple.
GC_malloc calls takes longer sometimes (gc done) or are quite fast.

malloc() can take longer if it needs to call the OS, and the OS can
take longer if it needs to swap a page to disk.

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

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.

True, the GC is not a panacea and, as anything, has it drawbacks.

For instance, if you forget to set to null a global variable pointing to a
huge memory block, it will not be freed, and your program may fail
because you always allocate a big chunk of memory without cutting
any pointers to it.

An advantage is that all objects with only one pointer to them
(typical case) will be freed if the function where the pointer resides
exits. All local variable pointers that use a malloced memory will
be no longer in scope when the function exists so the collector will find
no references to them.


 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      08-15-2003
On Fri, 15 Aug 2003 23:24:29 +0200, in comp.lang.c , "jacob navia"
<(E-Mail Removed)> wrote:

>> 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!


It MAY recycle it, there is no obligation to. In fact I've often
observed that it does not. Imagine you free a 24 byte block ,and your
next allocation requires a 1204 byte block. Makes more sense for the
OS to find a large enough space, rather than allocate only 24 bytes in
one place, and have to manage the "appears contiguous" issue.

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

>
>And this is not recycling Mark?


Recycling is reusing. Putting it back in the pool is not reusing it,
that happens when its reused.

>I mean what are you trying to achieve? Confusion?


I think you two have different meanings of "recycling". Marks is more
common I fear.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      08-16-2003
jacob navia wrote:
>
> "Malcolm" <(E-Mail Removed)> wrote in message
> news:bhjofn$dee$(E-Mail Removed)...
> >
> > However that language isn't C. Part of the philosophy of C is that every
> > statement, apart from a function call, compiles to only a few machine code
> > instructions. Therefore you can see where your cycles are going.
> >
> > Automatic garbage collection breaks that design principle.

>
> No. When you call malloc() you can expect a GC. Very simple.
> GC_malloc calls takes longer sometimes (gc done) or are quite fast.
>
> malloc() can take longer if it needs to call the OS, and the OS can
> take longer if it needs to swap a page to disk.
>
> Nothing in the language tells you how long malloc calls take.
> Free can be longer sometimes if free() consolidates some memory.
>
> 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.
>
> True, the GC is not a panacea and, as anything, has it drawbacks.
>
> For instance, if you forget to set to null a global variable pointing to a
> huge memory block, it will not be freed, and your program may fail
> because you always allocate a big chunk of memory without cutting
> any pointers to it.
>
> An advantage is that all objects with only one pointer to them
> (typical case) will be freed if the function where the pointer resides
> exits. All local variable pointers that use a malloced memory will
> be no longer in scope when the function exists so the collector will find
> no references to them.


Jacob,

GC notwithstanding, what is garbage collection?
I am writing a C module which would trap malloc/realloc/free etc and
maintain a list of pointers to and the sizes of the allocations. The
list is (normally) invisible to the user. When the user invokes
free(ptr) I look up ptr in the list. If I find it, I free the allocation
and free and remove the list node. If I don't find it (user gives me an
invalid pointer), I simply ignore it. I provide a freeall() function
which will free all allocated memory.

Does this qualify as garbage collection?
--
Joe Wright (E-Mail Removed)
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-16-2003
jacob navia wrote:
> "Gordon Burditt" <(E-Mail Removed)> wrote in message
>
> [snip]
> >
> > But, to continue the analogy, sometimes the automatic transmission
> > does it wrong when you're towing a trailer (hiding pointers where
> > the gc can't find them). Either it ruins the engine (frees memory
> > that should NOT be free), or it slows down horribly (spends enormous
> > amounts of time looking for pointers where they aren't) and takes
> > 24 hours to get home. And there's no practical way to fix this
> > without putting restrictions on how you drive.

>
> Yes, but I can go farther because I am less tired you see?
>
> Automatic driving requires less efforts from the driver and he/she
> can drive longer distances!
>
> For instance, I added the GC to the debugger/IDE of lcc-win32.
>
> Because I do not have to write any code to cope for free() bugs or
> problems, I used the saved time to improve the application itself.
>
> I concentrated in the debugger itself, a *very* complex application.
> Real time, with 3 threads running (debugger IDE, program under
> debug, and debugger itself), with many complex specs to read the
> debug info, messages that must be formated at each break, etc etc!
>
> Now, I know that I can allocate a buffer whenever I need one, and
> that I can pass it around without caring where I will free the stuff!!!
>
> Debugging the debugger is difficult. Without the GC I would have been
> slowed down by all those accounting chores and would have had less
> time to try to improve it.


Now this, to me, is a legitimate use of a GC package. It is mated
to the system programs themselves. A debugger, by nature, is a
non-portable application (although large portions of it should be
as portable as possible)

>
> Besides, the crashes due to messing around with free would be
> inacceptable. A debugger crashing, what a nightmare


However, the last time I looked, the lcc-win32 debugger still
crashes immediately when run on a 486 This doesn't happen
with gdb. (and I did report it).

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-16-2003
jacob navia wrote:
>

.... snip ...
>
> malloc() can take longer if it needs to call the OS, and the OS can
> take longer if it needs to swap a page to disk.
>
> Nothing in the language tells you how long malloc calls take.
> Free can be longer sometimes if free() consolidates some memory.


I have written a malloc/free/realloc package that ensures free is
O(1) at all times. You are welcome to use the ideas therein if
you wish. The free in crtdll (which I believe you use) is O(n),
where n is the number of blocks in play. So far I know of no
other RTL with an O(1) free.

See download/nmalloc.zip on my site.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Project management / bug management Floris van Haaster ASP .Net 3 09-23-2005 08:36 PM
queue management with "application failure management" pouet Java 2 07-30-2004 09:59 PM
CatOS web management or CiscoView management ? Martin Bilgrav Cisco 1 12-20-2003 01:49 PM
perl memory management - does @array = () free the memory? Matt Oefinger Perl Misc 0 06-25-2003 09:11 PM



Advertisments