«

"jacob navia" <> wrote in
news:bhjj2g$nv3$:

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

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

"Gordon Burditt" <> wrote in message
news:bhjkif$...
> >
[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

"jacob navia" <> 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.

On Sat, 16 Aug 2003 00:02:21 +0100, "Malcolm"
<> wrote:

>
>"jacob navia" <> 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

"Malcolm" <> wrote in message
news:bhjofn$dee$...
>
> 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.

On Fri, 15 Aug 2003 23:24:29 +0200, in comp.lang.c , "jacob navia"
<> 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 =---

jacob navia wrote:
>
> "Malcolm" <> wrote in message
> news:bhjofn$dee$...
> >
> > 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 private.php?do=newpm&u=
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

jacob navia wrote:
> "Gordon Burditt" <> 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 () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

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 () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!