Merging In The GNU D Language Compiler To GCC

[mirv]

C++ is meant to be flexible, and powerful. It's not meant to hold the programmer's hand. Many seem to forget that, so thought I'd mention it again.
On the subject of memory management and garbage collection within C++, however, I direct people to:

http://www2.research.att.com/~bs/bs_...age-collection

I personally think that garbage collector or no, a programmer should be aware of what they're doing with memory. Know if you've left something for later deallocation, know if you need things to stay around, know what your code is doing. Garbage collectors should not be relied upon to clean up bugs - that's just lazy and poor programming; the bugs shouldn't be there in the first place.

[ciplogic]

(...) I personally think that garbage collector or no, a programmer should be aware of what they're doing with memory. Know if you've left something for later deallocation, know if you need things to stay around, know what your code is doing. Garbage collectors should not be relied upon to clean up bugs - that's just lazy and poor programming; the bugs shouldn't be there in the first place.

The GC changes the code as it is. The difference between a GC and a non GC code is mostly: GC do guarantee that the references are to an either: allocated memory block or to null. In this way simply removing the references in a natural way (like not using the variable anymore) or by explicitly setting it up to null, will make references to be removed.
GC proved to have some good parts and drawbacks. The biggest drawbacks I think are that GC process can be slow, unpredictable, and is memory bandwidth dependent. The biggest features are in code that you don't know what it does, like for example big web frameworks. When you have to do a desktop application, sometimes the code can become messy, (I don't talk about me and you) because are multiple programming styles, broken paradigms, multiple contributors. For this kind of applications, C++ can be painful to be maintained. And for this reason people try to use another paradigms that will remove the small leak from here, the buffer overflow form there. Some may use an SqlLite database, or maybe a shell script to do a specific task, so if that shell script will leak memory, will basically not matter as the process will stop, the process will give back the used memory.
At the end not all GCs are equal. Most GCs are optimized for enterprise, meaning throughput. This means: if the pauses can be overcomed (it is done in most cases with a balancer) what matters is to remove most objects in the shortest time.
Another class of collectors are the D one, or in general the Boehm's ones, meaning they are C based collectors where they scan the stack and are conservative ones. They are the slowest in their class, but they do achieve a safe running program.
But the latest class of collectors are named "cycle collectors" which are mostly used by some JavaScript engines and ActionScript. So by default it is used a reference counting algorithm, and at the end if the GC is triggered, the GC will simply look for dangling cycles. As reference counting algorithms are mostly predictable, will make that the pauses to occur not that often, if ever and the pauses to be smaller. Yet this gives a performance hit over iterating in collections and need to be a tight coupling with compiler.
Is hard to achieve perfect GC and there is a lot of tuning to make it smooth. Is for a server bad when a GC happen in a cluster for a minute? In some way it does, but not to such of a great extend. On the other way is better to have a node be blocked for some time just doing GC if the task is migrated to another node. Is it bad if the GC will happen in a Mono application, like Pinta? Mostly you will not notice it, because the extra big allocations will be made in a non moving collector, so even a picture is referenced (or not referenced) the GC will let it as it was placed in memory. And about the small pauses that may appear at Undo/Redo, most users will not notice that was an extra 0.1 seconds as GC triggered.
What about JavaScript/ActionScript games? There are JavaScript, even Java games that do work just fine (look for Tanki). If you will compare the throughput, will be smaller compared with either C or Java allocators.
At the end the question I think is: if someone can make a well behaving application that works under our expectations, can it use std::strings, or it must use char* because is faster? It have to use direct arrays or STL? I think the answer is in developers' hands, not in complaining users. The same should be done on GCs: use them but when you should. Focus to make all of us (mostly happy), and don't take any rumor is around!

[bnolsen]

And the biggest point about GC that people seem to ignore....it doesn't scale very well to highly efficient multithreaded applications. The GC just gets in the way, bottlenecking execution and stalling threads out. You can do thread local storage at that point but then why would you want a GC attached to each and every thread?

IMHO "d" was designed when "garbage collection" was all the rage. Other complaints: the number of keywords in the language is staggering even compared to many mature languages current in widespread use.

When "D" was announced I was excited. c++ is pretty long in the tooth, compilation is slow, c++ compilers all implemented the spec differently. I was hoping "D" would be a better c++, cleaning up the stupidity. Instead they introduced questionable concepts themselves, loading up the language with somewhat questionable features based on "fads" from the 90's and early 00's.

[kayosiii]

And the biggest point about GC that people seem to ignore....it doesn't scale very well to highly efficient multithreaded applications. The GC just gets in the way, bottlenecking execution and stalling threads out. You can do thread local storage at that point but then why would you want a GC attached to each and every thread?

D does default to thread local storage. http://www.informit.com/articles/article.aspx?p=1609144
the current garbage collector could be implemented better however. you don't have to use the GC for your heavy lifting however.

IMHO "d" was designed when "garbage collection" was all the rage. Other complaints: the number of keywords in the language is staggering even compared to many mature languages current in widespread use.

When "D" was announced I was excited. c++ is pretty long in the tooth, compilation is slow, c++ compilers all implemented the spec differently. I was hoping "D" would be a better c++, cleaning up the stupidity. Instead they introduced questionable concepts themselves, loading up the language with somewhat questionable features based on "fads" from the 90's and early 00's.

As far as I can tell the majority of the extra keywords come from merging prepossessing and template meta programming into the core language.
I am not exactly sure which 90s-early 00s fads you are talking about.
Empirical and Functional programming have been popular for a lot longer than that.
Concurrent programming? I have a hard time concidering a Fad given the way that hardware is going.
Object Oriented programming (maybe - what's your rational there though)?
Template Meta Programming (perhaps - why is C++ adding a lot of the same features to c++11 though?)
Unit-testing (that would get you rid of 1 keyword)
Contract Programming (that would let you get rid of another keyword, 3 more if you remove features from other parts of the language).

I can understand wanting a smaller simpler language (perhaps go or vala?) would be more appealing. I just don't quite get your specific complaints.

[ciplogic]

A typical GC case when stack operations may break your code

I worked with strings and I encounter one case (I found it as crash occurs, if that means fun ) and is a Qt code like this:

const char *cStr = myQString.toAscii().data();

I do understand that was my mistake, and so on, but sometimes GC can make the code much cleaner without working with internals and to see that a variable is given on stack and you have to make a copy to not lose the data. as it deallocates when things get out of scope.

[movieman]

Not returning pointers to things allocated on the stack is easier then working around garbage collector crud. In fact, I'd imagine it's not hard for a compiler to warn you any time you do so.

BTW, another reason why garbage collection is a pain: after you gave your text editor the 1GB that it needs to run happily with garbage collection without long pauses, then it gets swapped out, then you open it up again and type something, it has to swap most of that memory back in so it can do a garbage collection.

[ciplogic]

Not returning pointers to things allocated on the stack is easier then working around garbage collector crud. In fact, I'd imagine it's not hard for a compiler to warn you any time you do so.

Obviously you noticed that the compiler do not have information about who has the ownership of life-cycle of the objects and I do agree that some class of problems can be solved in a lot of nice ways, was a real case when you can make mistakes and is real code. Also was reflecting the point that faster stack operations can lead to other risks. In general missing of GC means that you simply don't know for a pointer (excluding is NULL) that is valid or not (because can be deleted).

BTW, another reason why garbage collection is a pain: after you gave your text editor the 1GB that it needs to run happily with garbage collection without long pauses, then it gets swapped out, then you open it up again and type something, it has to swap most of that memory back in so it can do a garbage collection.

You did it wrong to give 1GB of memory to your text editor. Big heaps are used for big, long running applications. Anyway, did you notice that swapping can happen for C++ applications too? Did I miss something about OS architectures? In fact there are cases when independent of memory allocation strategies of different runtimes. For example Android will drop applications (in multitasking) based on memory usages.
At the end there are applications that do less, using C++ and use more memory than ones that use a GC. SharpDevelop loading the same projects (I tried for a 1000 classes project, SD will use 120M RAM, when VC# will use 140) will give consistently less memory usages that Visual C# Express, and reflects in almost 1:1 functionality. IntelliJ IDEA is fairly lean IDE. I am not justifying that writing counting every byte will not make C applications leaner, but people do not write in this way anymore.
Also as it was talked earlier GC algorithms are different, so there are desktop GCs which are small pause to increase responsiveness. If you use Ubuntu and it happen to use Banshee, I did not notice it to swap. If you used an installer of Ubuntu or Fedora, you probably noticed the killer pauses of the GC as the live ISO remained without RAM (pun intended!).
In fact there are so many GC based applications compared with the wisdom that they are too clumsy (Flash, Mono/.Net/Java, JavaScript, Python, Ruby with Rails), that I still wonder why there are people that are just defending irrationally the C++ language mechanics, when obviously other mechanisms work too. At the end the "managed" world is much bigger than a memory allocator abstraction, most people will use today SQL, and no one seem to attack it in case that it has other problems, like: what if the query is not well optimized and instead of 10ms will take 10 seconds to compute, also that there are enterprise like behaviors (Oracle, SQL Server, MySQL, and so on) which are optimized for throughput, which (obviously) behave different than an SQLite or Firebird. And applications use both, what if the database server will use huge memory that is not a part of application creator. What if when you execute a query, the server would use memory that enters on swap (remembering me on GC talks).
My observation: best tool (not only in raw performance terms, but in the way that problem is really solved, maintenance costs, skill set, and so on) for the needed problem.