Why garbage collector?

[Guest]

This might sound stupid, but I really need to know why we need another
language with garbage collector?

With C++ destructor, everything get destroyed without to worry about them.
And because memory is not the only system resources, the concept of
destructor fits well into object oriented programming practise.

For instance, if Java with reference counting and without GC exists:

// With destructor and reference counting
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
// rs and stmt went out of scope and destroyed
}

// With garbage collector
Statement stmt = null;
ResultSet rs = null;
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
} finally {
rs.close(); // What if createStatement() throws an exception and rs is
null???
stmt.close(); // Can you be sure that stmt is not null???
}

As you can see, GC only free programmers from handling memory but force
programmers to worry about other resources like file, database connection,
socket connection, etc. Why don't they implement a reference counting
language instead? We don't need another language like Java.

 

[Lloyd Dupont]

reference counting mechanism fail miserably with circular reference

also memory allocation in .NET is much faster than C++ because of GC
architecture

GC avoid error like double freing a memory zone, while it's easy to manage
only your object, what happen when you work with a 3rd party library? who is
responsiblefor freing object? how to enforce the same policy on all library
vendors?

to finish C++ does not perform much faster than C#, in some cases, such as
memory management it even perform slower, C# memory management is an area of
performance not the opposite, if only for that, I prefer it that way!

 

[Lloyd Dupont]

Also what I hate with C++ is that in most program, this 'so called' high
performance language wast heaps of instruction doing useless
copy/destruction.

in C# you just pass around the reference and you don't waste your time
creating copy again and again.......

 

[Jon Skeet [C# MVP]]

This might sound stupid, but I really need to know why we need another
language with garbage collector?

With C++ destructor, everything get destroyed without to worry about them.

If you don't have any circular references, maybe.

And because memory is not the only system resources, the concept of
destructor fits well into object oriented programming practise.

For instance, if Java with reference counting and without GC exists:

// With destructor and reference counting
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
// rs and stmt went out of scope and destroyed
}

And assuming you didn't have any circular references...

// With garbage collector
Statement stmt = null;
ResultSet rs = null;
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
} finally {
rs.close(); // What if createStatement() throws an exception and rs is
null???
stmt.close(); // Can you be sure that stmt is not null???
}

Well, in Java you'd handle that with two finally blocks. In C# you'd
handle that with two "using" statements.

As you can see, GC only free programmers from handling memory but force
programmers to worry about other resources like file, database connection,
socket connection, etc. Why don't they implement a reference counting
language instead? We don't need another language like Java.

Because reference counting is relatively slow, and doesn't handle
circular references.

 

[Guest]

This is a stupid question after all.

I almost forgot about circular reference. I'm sure gonna look into "using"
statement. Thanks for the quick reply, I just need to clear things up before
going into .Net.

 

[Peter van der Goes]

This might sound stupid, but I really need to know why we need another
language with garbage collector?

With C++ destructor, everything get destroyed without to worry about them.
And because memory is not the only system resources, the concept of
destructor fits well into object oriented programming practise.

For instance, if Java with reference counting and without GC exists:

// With destructor and reference counting
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
// rs and stmt went out of scope and destroyed
}

// With garbage collector
Statement stmt = null;
ResultSet rs = null;
try {
Statement stmt = conn.createStatement();
ResultSet rs = stmt.query("SELECT * FROM table");
// Do something
} catch (Exception e) {
// handle exception
} finally {
rs.close(); // What if createStatement() throws an exception and rs is
null???
stmt.close(); // Can you be sure that stmt is not null???
}

As you can see, GC only free programmers from handling memory but force
programmers to worry about other resources like file, database connection,
socket connection, etc. Why don't they implement a reference counting
language instead? We don't need another language like Java.

Please consider this:
Only *properly written* destructors free resources in C++, where garbage
collection abstracts developers from the details of memory resource
management. If all C++ programmers *always* did away with the garbage all
the time (which, historically, has not happened), perhaps the appeal of
automatic garbage collection would be less.

 

[Michael D. Ober]

Circular references aren't the only issue. Another big issue is that the
..NET GC also compacts memory so that the largest contiguous block of memory
is kept large. In C++ you can write programs that, although appear to be
memory frugal, can actually be memory hogs simply because the pattern of new
and delete statements at runtime leave lots of little holes in memory.
Almost all GCs, whether they be mark&sweep or reference counted move objects
around in the heap to consolidate free space.

Your other comment about there being other resources that must be managed is
also accurate. This is the difference between fully managed code runtime
environments such as .NET and semi-managed code runtime environments such as
VB 6.

Mike Ober.

 

[Richard Grimes [MVP]]

reference counting mechanism fail miserably with circular reference

the GC does not solve all circular reference issues, that's why the
framework has weak references.

also memory allocation in .NET is much faster than C++ because of GC
architecture

It's also very memory hungry. You win some, you lose some.

GC avoid error like double freing a memory zone, while it's easy to

That's more a feature of the security system. If the heap (or stack)
become corrupted in any way the execution engine shutsdown the
application immediately. I can write a handful of lines of code in

to finish C++ does not perform much faster than C#, in some cases,
such as memory management it even perform slower, C# memory
management is an area of performance not the opposite, if only for
that, I prefer it that way!

The garbage collection is extremely expensive and non-deterministic. You
have to factor this into your code design. The GC is useful, but it has
its issues.

Richard

 

[Richard Grimes [MVP]]

This might sound stupid, but I really need to know why we need another
language with garbage collector?

..NET remoting would not work without garbage collection. One of the most
important things in DCOM (and for that matter RPC) was to manage the
memory management of the parameters in a method. You have by value and
by reference, in, out and in/out and each had to have its own rules how
data was copied and who had the responsibility of cleaning up the memory
used. In .NET you do not need to bother because the GC cleans up the
memory.

Richard