Memory leak.

[rapidcoder]

The whole point of C with Classes was to guarantee initialisation and release of resources as it is always a common mistake that programmers make. The reliance on GC removes this benefit.

It is common mistake, but easy to catch and easy to fix. Open without close in the same method. Automatic code checking tools do that. ARM blocks do that. RAII is just a one of many solutions to the trivial problem.

But the real problem is when the resource associated with the object is long-lived and shared. RAII doesn't help with that at all. GC at least helps a little - you can force GC manually and see what leaks the resources (providing you have proper checks in the finalizers).

Now that sounds promising. Do you have an example?

ARM blocks. They can be implemented in different ways in different languages. But they do exist and they usually look something like that (pseudocode):

with (new BufferedReader(new FileReader("file"))) { reader =>   
   // ... here some code reading the file
}  // stream closed automatically here, even if an exception is thrown inside the block 

[kbw]

It is common mistake, but easy to catch and easy to fix ... trivial problem.

Trivial yes. Easy to fix, yes. Easy to catch, no. But point taken.

But the real problem is when the resource associated with the object is long-lived and shared.

It's not clear how ARM blocks are a solution to this as this only deals with objects used within a scope. What if they need to be released elsewhere? How do ARM blocks or GC help here?

[rapidcoder]

It's not clear how ARM blocks are a solution to this as this only deals with objects used within a scope. What if they need to be released elsewhere? How do ARM blocks or GC help here?

ARM blocks don't help here, just as RAII doesn't (you can forget to call delete and release the resource just as well as you can forget to call "close" or "dispose"). GC helps because when the object managing some resource becomes inaccessible, it will be freed after some time and it can at least display a warning that you should close it manually and not rely on the GC. This is more valuable information than just getting "too many open files" somewhere.

[kbw]

ARM blocks don't help here, just as RAII doesn't (you can forget to call delete and release the resource just as well as you can forget to call "close" or "dispose").

I think we've come full circle. We're no better off, and we're back to being as unsafe as we are in C.

GC helps because when the object managing some resource becomes inaccessible, it will be freed

This is exactly my point.

Memory isn't the resource we're really concerned about. Memory is just raw material for making objects. Objects are what we're concerned about. Just freeing the memory behind an object usually isn't sufficient. Sometimes the memory is used for benign things like strings, but more often, objects have handles to other things.

This fallback position of dependence on the GC is not a substitute for correct release of resources, however that is achieved. Hence my original possibly overstated comment, "I don't think using a garbage collector is a proper solution to any problem".

[rapidcoder]

Ok, I agree that GC is not a proper solution to general resource management problems (but - what is?). You see, sometimes it is important to think about object ownership and responsibility. But why do that for most of the objects, when you need it just for a few that manage resources other than memory? The fact that so many languages are GCed means something.

[kbw]

I see what you mean. Thanks.

[sohguanh]

The fact that so many languages are GCed means something.

It is indeed an indication of the direction to go as far as programming language is concerned. But from business systems perspective, especially for those high volume intensive in nature like stock trading, horse betting, bidding, ticketing etc etc when the spike in volume is always close to a close-off time, at that critical moment GC activated will be disastrous as every transaction lost is lost revenue for the companies.

That is why I say GC must find a way for such business systems in nature like maybe allowing a configurable setting say GC must not be fired at certain times preferably using API and it must give guarantee for that.

In other business systems without those requirements then GCed language is already in place and serve them pretty well.

PS Btw can anyone doing stock trading systems tell me are you using Java or GC'ed language for the real-time trading portion ? :P

[rapidcoder]

That is why I say GC must find a way for such business systems in nature like maybe allowing a configurable setting say GC must not be fired at certain times preferably using API and it must give guarantee for that.

You assumed here that firing GC stops the program. This is not true for modern GCs, especially commercial ones like that used by Azul in their servers (I'm not connected with Azul otherwise than by having occasion to use their products some time ago). They claim to have pauseless, hardware accelerated GC making GC overhead essentially 0. Also, even in current Oracle's JVM I can see that GC can run in parallel to the application, on a different CPU core, and no visible pauses occur.

The problems are with large heaps (>32 GB) and cache pollution caused by GC. I think, that without proper hardware support (like in PCs), we cannot fully benefit from GC.

[sohguanh]

Until the day NYSE or say Nasdaq IT head can come out and announce they use GC-ed language implementation for their trading system, it is hard to convince GC-ed language is able to support high volume intensive systems.

Maybe Oracle can implement a trading system on pure Java to prove a point isn't it :P

[kbw]

They do, or more accurately, I know one does.

The actual matching engines and other milli-second time critical systems are in C/C++, but the control systems that the business use to monitor the environment can be written in C# or Java.

[sohguanh]

The actual matching engines and other milli-second time critical systems are in C/C++

The above statement is what I am referring actually. Can a GC-ed language perform the above component required by business requirements ?

If the answer is a resounding YES then I guess C/C++ will soon be obsoleted :P

[rapidcoder]

If the answer is a resounding YES then I guess C/C++ will soon be obsoleted

I don't think so. Trading systems are not the end of all things. What about games or embedded systems?

There are/were at least some Java based open-source trading systems.
http://www.marketcetera.org/
They sell support for it, so probably someone earns money on it, but no info who are their customers.