Garbage collection

S

santosh

Eligiusz Narutowicz wrote:

Personally I do not like GC - I think it encourages lazy thinking and
if you then go back to a non GC C environment then possibly this lazy
thinkings will be causing bugs.

I would be interested to hear your views on what you mean by "lazy
thinking" in this context.

Personally I consider it lazy programming (in a manual malloc -> free
context) to free some memory but not others. With a GC of course you
don't free anything at all. However a poor GC which fails to pick up
eligible objects may itself be called "lazy" I suppose. :)

Also (at least in the context of C programming) even if one uses a GC
other resources like file streams, file descriptors, mmap'ed objects
still need to be freed manually. Typically they are much scarcer than
memory too! So it pays (IMHO) to get into the practise of closely
tracking all your program resources early on, if you ever want to be a
good C or C++ programmer.
 
E

Eligiusz Narutowicz

santosh said:
I think the point that Flash is making is that malloc *can* fail. In a

Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.
fault-intolerant environment, you want to keep chances of failures to a
minimum. In a important section of code, what should be done if malloc
returns NULL due to some reason or the other, like say memory
fragmentation? The options open to desktop or general purpose programs
(like calling exit, abort etc.) may not be acceptable at in some
contexts. Recursion *can* be used safely, but again it simply opens up
the program to more chances of failure and consumes excessive resources
in a very likely resource constrained environment.

So I would say that for certain limited types of applications Flash's
recommendations are entirely sensible.

Very, very, very , very limited yes.

But if you program for worst case then you might as well give up in my
opinion.
 
E

Eligiusz Narutowicz

santosh said:
Eligiusz Narutowicz wrote:



I would be interested to hear your views on what you mean by "lazy
thinking" in this context.

Very easy to define. Not thinking about memory allocation and
deallocations and using it like a free never ending resource with it
being given back when you dont need it. It encourages poor flow and
optimizations I think and is why MOST Java programs I come across over
the years are buggy, slow and use too much memory.
Personally I consider it lazy programming (in a manual malloc -> free
context) to free some memory but not others.

So do I. But worse. It is rubbish, buggy programming.
With a GC of course you
don't free anything at all. However a poor GC which fails to pick up
eligible objects may itself be called "lazy" I suppose. :)

Of course. Personally I am using C for a reason - efficiency. GC removes
a lot of that.
Also (at least in the context of C programming) even if one uses a GC
other resources like file streams, file descriptors, mmap'ed objects
still need to be freed manually. Typically they are much scarcer than
memory too! So it pays (IMHO) to get into the practise of closely
tracking all your program resources early on, if you ever want to be a
good C or C++ programmer.

You seem to be repeating what I say.
 
H

Hallvard B Furuseth

santosh said:
CBFalconer wrote:
[ ... ]
I prefer to trust my own judgment than that of some unknown.

Now if everybody said the same...

Different kind of risk.

With GC in safety-critical programs, the question is "will this be the
time the collector pauses the program for a dangerously long time in
order to do its job, or fails to collect enough memory?"

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

Bartc

What can be tested and checked is a well marshalled malloc/free
access. God knows I have worked on enough C progrms which are large and
do not leak memory.

I hadn't even thought about memory leaks. Only that dynamic memory is more
complex and therefore full of nasty surprises.
Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.

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

Which would most people prefer in their critical software?

No matter how brilliant a programmer you are, you have to allow for the
possibility of malloc() failing for some inexplicable reason.
 
E

Eligiusz Narutowicz

Bartc said:
What can be tested and checked is a well marshalled malloc/free
access. God knows I have worked on enough C progrms which are large and
do not leak memory.

I hadn't even thought about memory leaks. Only that dynamic memory is more
complex and therefore full of nasty surprises.
Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.

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

Which would most people prefer in their critical software?

No matter how brilliant a programmer you are, you have to allow for the
possibility of malloc() failing for some inexplicable reason.

Its nothing to do with being a brilliant programmer. Most "real
programs" use malloc to dynamically allocate memory which is then
retained and passed around functions to be reused/processed - in
addiition the size of the malloc often alters depending on process
parameters.

I'm sorry but I do not see or agree with this sudden "malloc is evil"
trend. Malloc usage is not trivial. Neither is good systems programming.
 
J

jacob navia

Eric said:
jacob said:
santosh said:
[...]
If this is
so, and in due course the program fails to run because of an
out-of-memory situation due to the GC failing to collect blocks that it
should have, would you still say that such software can be reliably
used in safety or performance critical contexts?

Of course not. And I am not proposing that a conservative GC
that is OK for desktop applications be used in an airplane software.

Well, you *did* ridicule George Peter Staplin, saying

:> Incredible. And you will trust your life to the ability of a
:> programmer to avoid bugs in MANUALLY done memory management?
:>
:> I would prefer GC at any time!

... with the clear implication that automatic garbage collection
*is* safe for use in software on which lives depend. Would you
care to explain the apparent contradiction between your responses
to Mr. Staplin and to santosh?
As all other certifications process for complex software go.

You described *that* process to Eligiusz Narutowicz, saying

:> [...] a moderately complex piece of software can't be tested
:> exhaustively since the exponential growth of the combinations
:> of input parameters, interrupts, timing considerations, possible
:> paths through the software etc makes exhaustive testing impossible.
:> [...]
:> But no amount of testing will make bugs go away, [...]

Since a garbage collection system is "a moderately complex
piece of software," it follows that Program P plus GC has more
bugs than Program P standing by itself.

Obvious. The GC is as untestable as any other big piece of software.

But when you use it, you are using a piece of software that can be
tested in many applications and much more situations than a specific
malloc/free combination. It is MODULE that can be tested separatedly.

Malloc/free combinations are embedded in your software and can't be
tested independently from it. This makes it much more difficult to test.

In some environments, a conservative GC is not allowed because of the
small memory leak that it implies. Then, another type of GC can be
used, that is reused over and over again in certain applications with
certain patterns of allocation/deallocation.

Many types of GC have been used, and a GC with compiler support would be
much more precise than a conservative one like Boehm's.
 
J

jacob navia

Eligiusz said:
Bartc said:
What can be tested and checked is a well marshalled malloc/free
access. God knows I have worked on enough C progrms which are large and
do not leak memory.
I hadn't even thought about memory leaks. Only that dynamic memory is more
complex and therefore full of nasty surprises.
I think the point that Flash is making is that malloc *can* fail. In a
Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.
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? */

Which would most people prefer in their critical software?

No matter how brilliant a programmer you are, you have to allow for the
possibility of malloc() failing for some inexplicable reason.

Its nothing to do with being a brilliant programmer. Most "real
programs" use malloc to dynamically allocate memory which is then
retained and passed around functions to be reused/processed - in
addiition the size of the malloc often alters depending on process
parameters.

I'm sorry but I do not see or agree with this sudden "malloc is evil"
trend. Malloc usage is not trivial. Neither is good systems programming.

Obvious. malloc is not "evil". But it is error prone, and can fail
if there is a memory leak in the system. Memory leaks can happen in a GC
environment too.

As you know, if you hold a pointer to an object, the GC will not touch
it. But if you hold a pointer to an unneeded object without you
realizing it you have a memory leak WITH A GC!

I am not saying that GC is the best since sliced bread. I am saying that
it is a technique that can SIMPLIFY programming. And by simplifying
programming it makes it less error prone.
 
J

jacob navia

Eric said:
jacob said:
Eric said:
jacob navia wrote:
:>
:> But no amount of testing will make bugs go away, [...]

Since a garbage collection system is "a moderately complex
piece of software," it follows that Program P plus GC has more
bugs than Program P standing by itself.

Obvious. The GC is as untestable as any other big piece of software.

All right, "The GC is untestable."

Untestable EXHAUSTIVELY.

If you are going to play word games (like the regulars love to do)
just forget this discussion.
All right, "The GC can be tested."

Can be BETTER tested than a malloc/free approach since it is SEPARATED
FROM THE APPLICATION.

It can be tested in ISOLATION, therefore the range of tests that can be
used is more extensive.

That was my argument that you didn't even bother to argue.
 
E

Eligiusz Narutowicz

jacob navia said:
Eric said:
jacob said:
Eric Sosman wrote:
jacob navia wrote:
:>
:> But no amount of testing will make bugs go away, [...]

Since a garbage collection system is "a moderately complex
piece of software," it follows that Program P plus GC has more
bugs than Program P standing by itself.


Obvious. The GC is as untestable as any other big piece of software.

All right, "The GC is untestable."

Untestable EXHAUSTIVELY.

If you are going to play word games (like the regulars love to do)
just forget this discussion.
All right, "The GC can be tested."

Can be BETTER tested than a malloc/free approach since it is SEPARATED
FROM THE APPLICATION.

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 can be tested in ISOLATION, therefore the range of tests that can be
used is more extensive.

That was my argument that you didn't even bother to argue.

Testing in isolation is immaterial. It has to work with the rest of the
system. Look up Heisenbugs.

http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs

For my thinking using GC in C I might as well have chosen Java in the
first place.
 
J

jacob navia

Eligiusz said:
jacob navia said:
Eric said:
jacob navia wrote:
Eric Sosman wrote:
jacob navia wrote:
:>
:> But no amount of testing will make bugs go away, [...]

Since a garbage collection system is "a moderately complex
piece of software," it follows that Program P plus GC has more
bugs than Program P standing by itself.

Obvious. The GC is as untestable as any other big piece of software.
All right, "The GC is untestable."
Untestable EXHAUSTIVELY.

If you are going to play word games (like the regulars love to do)
just forget this discussion.
But when you use it, you are using a piece of software that can be
tested in many applications and much more situations than a specific
malloc/free combination. It is MODULE that can be tested separatedly.
All right, "The GC can be tested."
Can be BETTER tested than a malloc/free approach since it is SEPARATED
FROM THE APPLICATION.

This is of course total rubbish. One can wrap malloc/free and log
mallocs and frees easily enough.

But this is nonsense. If you "wrap" malloc

char *a = mymalloc(sizeof(buf)+sizeof(data));
......
myfree(a);

The CALLS are embedded in the application anyway. They can't
be tested OUTSIDE and with a wider range of tests.


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!


Testing in isolation is immaterial.

Excuse me but then you do not know anything about software testing.
The FIRST thing you do is to test separate modules independently,
THEN test the whole.
> It has to work with the rest of the
system. Look up Heisenbugs.


But Heisenbugs can only be discovered if you see them AFTER you
have tested individually!
http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs

For my thinking using GC in C I might as well have chosen Java in the
first place.

And what's wrong with Java?

It has many good ideas, among others the garbage collector, that was
copied from Lisp, one of the first languages to offer a GC. I am not
a language fanatic and I see the pros and cons of things.
 
J

jacob navia

Eric said:
How can you test a garbage collector "in isolation," when
there's nothing to generate garbage for it?

By generating patterns of allocation that test specific parts of the
collector, thread safety etc etc.

Test harnesses?

Of course. How can you test it if not?
Why couldn't test harnesses also be written and run for the
(far simpler) malloc() suite of functions?

You can test malloc/free, but you can't test if this malloced piece
of RAM has been freed correctly or not and THAT IS THE POINT HERE!
It didn't occur to me that rational argument would make
any impression on you.

It didn't occur to you that arguing, exposing your arguments and
understanding other people's arguments has any sense. You are a
typical regular Mr Sossman. No arguments, just polemic.
By the way, you still haven't explained the contradiction
between your replies to Staplin ("GC is safe enough to entrust
one's life to")

Read again. I said that an automatic process of memory management
(GC) is safer than many calls to malloc/free.

and to santosh ("I never said GC should be
used in airplane software").

Read again. I said that a CONSERVATIVE GC is not OK for airplane
software because it can leak memory because random correspondence
between pointers and other data in the stack.

Even if you use your error prone malloc/free, you have to do a GC and a
consolidation of free memory anyway!
 
I

Ian Collins

jacob said:
But this is nonsense. If you "wrap" malloc

char *a = mymalloc(sizeof(buf)+sizeof(data));
......
myfree(a);

The CALLS are embedded in the application anyway. They can't
be tested OUTSIDE and with a wider range of tests.
A common technique for tracking memory allocations and frees is to
provide a logging implementation for testing. Remember it isn't the
allocation functions that are being tested, its the balance of
allocations and frees.
Excuse me but then you do not know anything about software testing.
The FIRST thing you do is to test separate modules independently,
THEN test the whole.
Indeed.
 
J

jacob navia

Gordon said:
I'd give garbage collection a break here and not require it to
collect until another block is requested, or until it needs another
block from the OS.

Yes, that is how the GC works, BUT if you call GC() or you
allocate a block and the collector makes a scan, it SHOULD
ind all the blocks that are not in use! I was referring to those
bugs in the collector.
> And C implementations that don't know what's
*in* memory blocks may get fooled by data that isn't a pointer
looking like one.


Yes, this is a really nasty problem and would be an issue in the
"pointers stored in files" or "encrypted pointers" situations.
Fortunately, these are *very* uncommon.

Yes, but I wasn't referring to those, I ws referring that you hold
a legal pointer and even if you hold it the GC frees it because
it misses the pointer in the stack , or fails to scan all globals,
whatever.
^^^^^^^^^^^^^^^^^^^^^^^^^
So, you're saying that one of the OTHER non-standard-conforming
features of a GC is that you can't use garbage-collectable memory
in a signal handler?

Yes you can use it. I was referring to the process of scanning memory
for adjacent blocks and trying to build bigger blocks from scattered
pieces of memory.
 
I

Ian Collins

jacob said:
You can test malloc/free, but you can't test if this malloced piece
of RAM has been freed correctly or not and THAT IS THE POINT HERE!
Oh but you can, in the same way you test a collector does the same. See
my other reply.
 
I

Ian Collins

Gordon Burditt wrote:

[who said this? Boy you're rude.]
^^^^^^^^^^^^^^^^^^^^^^^^^
So, you're saying that one of the OTHER non-standard-conforming
features of a GC is that you can't use garbage-collectable memory
in a signal handler?

Note I said *use*, not allocate (or free, if explicit freeing is
even possible).
No GC used with C can compact the heap.

Where languages are designed to use GC, objects can be moved in memory,
allowing the GC to compact the heap. Thus C with GC looses one of the
key benefits of Garbage Collection.
 
F

Flash Gordon

Hallvard B Furuseth wrote, On 27/04/08 20:23:
santosh said:
CBFalconer wrote:
[ ... ]
I prefer to trust my own judgment than that of some unknown.
Now if everybody said the same...

Different kind of risk.

With GC in safety-critical programs, the question is "will this be the
time the collector pauses the program for a dangerously long time in
order to do its job, or fails to collect enough memory?"

Also has memory been too fragmented (try proving it won't get too
fragmented!)? Also is memory going to leak because a pointer is being
kept somewhere?
With CBFalconer-code the question is "has cbfalconer.home.att.net
recently been outsourced to some kid in India?"

Not an issue on safety critical projects because they are audited and if
it has been outsourced this will be known.
This is why GC is the best choice for safety-critical programs nowadays.

No, the best choice is to avoid dynamic memory allocation altogether in
most instances because it prevents you from proving that you will always
have enough memory for what you need to do.
 
F

Flash Gordon

jacob navia wrote, On 27/04/08 21:53:
Eligiusz said:
Bartc said:
What can be tested and checked is a well marshalled malloc/free
access. God knows I have worked on enough C progrms which are large and
do not leak memory.
I hadn't even thought about memory leaks. Only that dynamic memory is
more complex and therefore full of nasty surprises.

I think the point that Flash is making is that malloc *can* fail. In a
Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.
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? */

Which would most people prefer in their critical software?

No matter how brilliant a programmer you are, you have to allow for
the possibility of malloc() failing for some inexplicable reason.

Its nothing to do with being a brilliant programmer. Most "real
programs" use malloc to dynamically allocate memory which is then
retained and passed around functions to be reused/processed - in
addiition the size of the malloc often alters depending on process
parameters.

I'm sorry but I do not see or agree with this sudden "malloc is evil"
trend. Malloc usage is not trivial. Neither is good systems programming.

Obvious. malloc is not "evil". But it is error prone, and can fail
if there is a memory leak in the system. Memory leaks can happen in a GC
environment too.

Jacob and I agree :)
As you know, if you hold a pointer to an object, the GC will not touch
it. But if you hold a pointer to an unneeded object without you
realizing it you have a memory leak WITH A GC!

I am not saying that GC is the best since sliced bread. I am saying that
it is a technique that can SIMPLIFY programming. And by simplifying
programming it makes it less error prone.

However you also have to prove that the GC is correct in a safety
critical environment (not such a big deal in other environments).

Actually, I would be most concerned with fragmentation since proving
that memory isn't going to get fragmented will be a real bitch.
 
R

Richard Tobin

Ian Collins said:
No GC used with C can compact the heap.

Not with an off-the-shelf C compiler, at least. It should be possible
to produce a C implementation that reliably knows which locations are
pointers, and have the GC adjust them accordingly. You would have to
impose some more restrictions of the kind that conservative GCs
already have concerning the "hiding" of pointers.

-- Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top