This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster compilation speed

Robert Dewar wrote:

< GCC did not switch from obstacks to garbage collection because of
any inherent love for garbage collection. Using garbage collection
instead of obstacks was the most efficient way to support other features
which were added to GCC 3.0.

It also removes a pernicious variety of bug that often caused nasty memory
corruption in earlier versions of GCC. Our experience with the back end of
GCC (from the point of view of GNAT) is that code generation errors have
been a much more serious problem than time and space requirements.

You can dramatically reduce the pernicious variety of bugs introduced by memory management techniquies by designing memory management into the solution.

In our most recent project we decided to use a scheme or smart pointer templates that do virtually all the hard work of making sure reference counting is managed properly. We have the regular garden variety smart pointer and we also have 2 other types we use to indicate the passing conventions. One type is "orphan" usually the type when a reference is being returned or passed into a function, this type is instrumented in debug builds to assert if a transfer of the reference did not happen - this catches a huge number of leaks. We also have a type called "warded" that indicates that there is no transfer of responsibility to release the pointer. So, all reference counted pointers are managed using these 3 types, no raw pointers (except from new) are exposed. Since using this scheme, we have had very few errors and very efficient lifetime management.

As for the cyclic references, we use a different model, it's similar to the "weak" reference mechanism. In other words, we've designed away cyclic references.

Another project I worked on where we used refernce counting and cyclic graphs we also had associated with each object it's relationship with a `life-time' object. We could happily construct and build whatever graphs we needed and simply erase the entire graph by eliminating all objects withing that life-time. This meant that we needed to use data structures that you could remove or any objects indiscriminatly (inform near-by objects they were going away so everything had forward and backward references).

People might be anti c++, but this is where I think it shines.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]