Garbage collection

[jacob navia]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple
explanation for this. Languages without automated garbage collection are
getting out of fashion. The chance of running into all kinds of memory
problems is gradually outweighing the performance penalty you have to
pay for garbage collection.
<end quote>

lcc-win has been distributing a GC since 2004.

It really helps.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Friedrich Dominicus]

George Peter Staplin <ge************ ***@xmission.co mwrites:

Some people are content with a few false references and thus the Boehm
GC works for them. I hope that their software isn't used for something
involving human lives, and that the allocations retained aren't
large.

Well I bet C is used in that area also. I just can hope it was
"tested" long and well enough to not contain any of the typical bugs
which plagues us C programmers.

Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

Thanks for this interesting link. I did not know it, but looking over
it the suggestions seems to be better not using C++ at all. I can
agree witht that wholeheartly ;-)

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

George Peter Staplin <ge************ ***@xmission.co mwrites:

>
Unfortunately making an accurate GC for C would require compiler
support, and even then it would break in some cases due to the design of
C.

Yes it would change considerably instead of
"The programmers knows what he does" it would be
"The programmer knows what he does but I know better in the dynamic
memory allocation area"

that alone suggest it would be more complex ;-)

>
Some people are content with a few false references and thus the Boehm
GC works for them. I hope that their software isn't used for something
involving human lives, and that the allocations retained aren't
large.

I can not folow the arguments follow you mean the GC has bugs while
collecting things it is not supposed to collect or how do I have to
understand that.

This thread now has goten quite long. And many good and not so good
arguments were brought up. But seein it in a context of safety-critial
I think it's just one part (and I would think a smaller problem) to
have or not to have GC.

I for my part am nervouis with both alternatives, and I think
programmers should feel a bit uneasy about that area be it that they
support GC or beeing against it. There are so many other things which
can go wrong.

But let's see what might lead to use of C despite it's
shortcomings. It seem one thing C is well beyond nearly every other
language under the programming sun is that C compilers are now around
for more than 50 years. And the shortcomings have been surely
recogniced and they lead to a really big industry for "handling those
shortcomings". So I'd argue there's hardly a language whith more tools
for "getting around the early design decisions" than for every other
language.

Well nearly every other language does not need them. But are those
tools as mature? The questions still would be how one can judge that?
For C the "history of things implemented" is IMHO a hint on how "good
C really is" nearly all our "base tool" are based on C. Be it the
Operating Systems, Databases or any kind of Server. So I think one can
conclude that C is in the top of the maturity list. Probably this has
lead to use C in areas where there might be (theoretical or practical)
better alternatives. Howerver any time I read about safety-critical
software I have a somehow ungut feeling. But isn't somehow larger
while thinking of using GC with C or sticking to the manual memory
handling....

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[Bartc]

"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:5a******** *************** *******@bt.com. ..

Eligiusz Narutowicz said:

....

>This is of course total rubbish. One can wrap malloc/free and log
mallocs and frees easily enough. You seem to be intent on making it into
some sort of impossible task. History states that it isn't. There are
plenty of reliable and long lasting C projects you know!

It's not just easy. It's almost trivial.

Sure. Have a look at 4.26 p.59 here as to why they restrict use of
malloc/free. This is nothing to do with how able the programmer is:

"Chris Thomasson" <cr*****@comcas t.netwrote in message
news:g-*************** *************** @comcast.com...

JSF C++ standards:
http://www.research.att.com/~bs/JSF-AV-rules.pdf

And I mentioned (if I can quote myself!) regarding avoid use of malloc():

Compare these two pieces of code:
(1)
char array[10000];

(2)
char *array;
array=malloc(10 000);
if (array==NULL) puts("YOU'RE DEAD"); /* what else can it do? */

That's must be plenty of code examples so complex (I'm thinking in terms of
recursive stuff) where: (a) you can't determine easily if it will run out of
memory, even ignoring fragmentation issues; (b) nor whether you can always
balance malloc() and free(); (c) if malloc() fails recovery is next to
impossible.

So it can only be almost trivial where the program itself is almost trivial
(in complexity and runtime unknowns rather than in size).

--
Bartc

[jacob navia]

Bartc wrote:

"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:5a******** *************** *******@bt.com. ..

>Eligiusz Narutowicz said:

...

>>This is of course total rubbish. One can wrap malloc/free and log
mallocs and frees easily enough. You seem to be intent on making it into
some sort of impossible task. History states that it isn't. There are
plenty of reliable and long lasting C projects you know!

It's not just easy. It's almost trivial.

Sure. Have a look at 4.26 p.59 here as to why they restrict use of
malloc/free. This is nothing to do with how able the programmer is:

"Chris Thomasson" <cr*****@comcas t.netwrote in message
news:g-*************** *************** @comcast.com...

>JSF C++ standards:
http://www.research.att.com/~bs/JSF-AV-rules.pdf

And I mentioned (if I can quote myself!) regarding avoid use of malloc():

>Compare these two pieces of code:
(1)
char array[10000];

(2)
char *array;
array=malloc(1 0000);
if (array==NULL) puts("YOU'RE DEAD"); /* what else can it do? */

That's must be plenty of code examples so complex (I'm thinking in terms of
recursive stuff) where: (a) you can't determine easily if it will run out of
memory, even ignoring fragmentation issues; (b) nor whether you can always
balance malloc() and free(); (c) if malloc() fails recovery is next to
impossible.

So it can only be almost trivial where the program itself is almost trivial
(in complexity and runtime unknowns rather than in size).

For Mr Heathfield all is trivial... He doesn't even need a debugger most
of the time. Superman comes to him to receive lessons in programming.

Now, he could be a millionaire because all people that buy expensive
malloc debugging tools would switch to his trivial method and pay HIM
instead of all those expensive tools...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Hallvard B Furuseth]

I wrote:

(...)
With CBFalconer-code the question is "has cbfalconer.home .att.net
recently been outsourced to some kid in India?"

This is why GC is the best choice for safety-critical programs nowadays.

Clearly forgetting the ":-)" was unfortunate. Sorry about that.

--
Hallvard

[Ian Collins]

jacob navia wrote:

>
For Mr Heathfield all is trivial... He doesn't even need a debugger most
of the time. Superman comes to him to receive lessons in programming.

Now, he could be a millionaire because all people that buy expensive
malloc debugging tools would switch to his trivial method and pay HIM
instead of all those expensive tools...

Na, I'll stick with the excellent and free tools my platform of choice
provides.
--
Ian Collins.

[Stuart]

"Hallvard B Furuseth" <h.**********@u sit.uio.nowrote in message
news:hb******** ******@bombur.u io.no...

>I wrote:

>(...)
With CBFalconer-code the question is "has cbfalconer.home .att.net
recently been outsourced to some kid in India?"

This is why GC is the best choice for safety-critical programs nowadays.

Clearly forgetting the ":-)" was unfortunate. Sorry about that.

It would have clarified things somewhat ;-)

--
Stuart

[Flash Gordon]

Hallvard B Furuseth wrote, On 28/04/08 11:25:

I wrote:

>(...)
With CBFalconer-code the question is "has cbfalconer.home .att.net
recently been outsourced to some kid in India?"

This is why GC is the best choice for safety-critical programs nowadays.

Clearly forgetting the ":-)" was unfortunate. Sorry about that.

Hey, it happens.
--
Flash Gordon

[Chris Thomasson]

"jacob navia" <ja***@nospam.c omwrote in message
news:fv******** **@aioe.org...

Bartc wrote:

[...]

>And I mentioned (if I can quote myself!) regarding avoid use of malloc():

>>Compare these two pieces of code:
(1)
char array[10000];

(2)
char *array;
array=malloc( 10000);
if (array==NULL) puts("YOU'RE DEAD"); /* what else can it do? */

That's must be plenty of code examples so complex (I'm thinking in terms
of
recursive stuff) where: (a) you can't determine easily if it will run out
of
memory, even ignoring fragmentation issues; (b) nor whether you can
always balance malloc() and free(); (c) if malloc() fails recovery is
next to impossible.

So it can only be almost trivial where the program itself is almost
trivial
(in complexity and runtime unknowns rather than in size).

For Mr Heathfield all is trivial... He doesn't even need a debugger most
of the time. Superman comes to him to receive lessons in programming.

[...]

There are "some" ways to "attempt" to handle resource errors. For instance,
when I used to program server applications I would always "attempt" to
handle an allocation error like:
void server_emergenc y_resource_shri nk(int force) {
/* reduce sizes of all existing caches */
/* reduce max buffer sizes */
/* reduce system settings */
/* reduce working set */
/* attempt to reset/shrink region allocators */
/* shutdown non-critical services */
/* check for timeout connections */

if (force) {
/* forcefully drop connections */
/* forcefully destroy cached connection info */
}

/* ect, ect... */
}
void server_emergenc y_resource_crit ical() {
/* we are screwed!!! :^o */
}
void* server_private_ allocate(size_t sz) {
void* ptr = malloc(sz);
if (! ptr) {
server_emergenc y_resource_shri nk(0);
if (! (ptr = malloc(sz))) {
server_emergenc y_resource_shri nk(1);
if (! (ptr = malloc(sz))) {
server_emergenc y_resource_crit ical();
return NULL;
}
}
}
return ptr;
}

Try to reduce program state after an allocation error, and try again... If
it still fails, try to handle gracefully, user prompt, whatever, try and
avoid crashing.