Re: [boost] request for interest in a garbage collection library
One of the advertised advantages was that is was written purely in standard C++, which isn't the case of Boehm which isn't portable.
I am sure Boehm supports so many platforms and many compilers. Even so, an interpretation from C to ISO C++ is enough for that problem.
auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); This raises undefined behaviour, I believe.
gc allocated memory slab is always zero, so there would be no live pointers on the traced_buffer memory slab. I think we the concept of the GC should encapsulate two things separately. memory allocation/deallocation object construction/destruction [example class foo; { auto_ptr< foo > foo_bar(new (gc) foo()); } // call foo_bar->~foo(); example] the RAII call the destructor but the memory that was occupied is not necessarily free. the gc::collect(), collects the memory as well as calling the destructor for non-destructed objects. -- Kasra
Kasra wrote:
auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); This raises undefined behaviour, I believe.
gc allocated memory slab is always zero, so there would be no live pointers on the traced_buffer memory slab.
C++ doesn't allow you to call delete on a pointer type you allocated with new some_array_type, whether the type of the elements is a POD or not. That is what raises the undefined behaviour here. If you test your code with a type that traces construction and destruction, you will see only the first element of the array gets destructed, which is incorrect. Or your program might just crash.
My 2-cents. My first penny: Although the thought of having memory-leaks become a concept of the past is pretty nifty to me by using a memory-managing programming language, the "garbage collectors" of today make no promises to the programmer about any other type of resource. Brute-force programming and RAII are our current protections against mismanaging these other resource types. If we end up using RAII in our apps because object destructors must be called in deterministic fashion, then the advantage of GC almost becomes irrelevant. My second penny: There is one feature of an advanced GC that is super-beneficial to me however. The C++/CLI garbage collector has the ability to perform data compaction. Basically, when the GC activates, it removes the unused objects, and then fills in the vacated memory gaps with existing live objects, thus compressing memory usage. This ability can help you create applications that can run 24/7 ( basically forever ) without having any memory fragmentation. This to me is a better feature of the garbage collector. I personally don't know how the CLI engine performs this neat trick but it works, and the code generated by the compiler is crisp, compact and efficient. I don't know if there's a C++ based GC library out there that does this sort of thing. Ok, one final cent: The GC's provided within programming languages are much more compelling than library-based ones. For me, the way they can be improved is by following these simple rules: 1) Eliminate all object memory that is no longer referenced ( standard feature ) 2) Have destructor functions be called in a deterministic manner ( finalizers optional ) 3) Have data compaction within the memory manager 4) Have the ability to manage other system resources as well 5) Provide the ability to manually manage specific resources ( for RTOS ) The "Garbage Collector" should be ideally renamed to "Resource Manager". Until these features mentioned above are given to me by a single language infrastructure, I believe I will be forced to resort to RAII as my most-trusted tool. -Sid Sacek
Sid Sacek wrote:
There is one feature of an advanced GC that is super-beneficial to me however. The C++/CLI garbage collector has the ability to perform data compaction. Basically, when the GC activates, it removes the unused objects, and then fills in the vacated memory gaps with existing live objects, thus compressing memory usage. This ability can help you create applications that can run 24/7 ( basically forever ) without having any memory fragmentation. This to me is a better feature of the garbage collector. I personally don't know how the CLI engine performs this neat trick but it works, and the code generated by the compiler is crisp, compact and efficient. I don't know if there's a C++ based GC library out there that does this sort of thing.
Compacting (or otherwise moving) garbage collectors require detailed knowledge. They must know where the pointers to the moved objects are and modify them. Conservative GCs do not know this. They assume that every value that could be a pointer to an object actually is one. This works as long as they're read-only, i.e. they just look where the pointers are. Once they start modifying (as a moving GC would), this is no longer sufficient. Previously, the only danger was that an object would live longer than it should. Now, the GC could silently and not really deterministically modify miscellaneous values in the program. You can't implement a moving GC as a library unless the language already offers detailed type information, stack maps, register maps, and strict type safety. C++ doesn't do any of these things by default, and even an implementation generating the first three would have trouble with the fourth. Sebastian
Sebastian Redl wrote:
Compacting (or otherwise moving) garbage collectors require detailed knowledge. They must know where the pointers to the moved objects are and modify them. Conservative GCs do not know this.
But precise ones do. And precise garbage collection can be implemented in C++ just fine.
Mathias Gaunard wrote:
Sebastian Redl wrote:
Compacting (or otherwise moving) garbage collectors require detailed knowledge. They must know where the pointers to the moved objects are and modify them. Conservative GCs do not know this.
But precise ones do. And precise garbage collection can be implemented in C++ just fine. Yes, but only if you use special self-registering smart pointers (GC handles) for all GC pointers. This registering happens at runtime, so it's a performance hit compared to systems where this information is generated at compile time (or JIT time).
Sebastian
Sebastian Redl wrote:
and modify them. Conservative GCs do not know this. But precise ones do. And precise garbage collection can be implemented in C++ just fine. Yes, but only if you use special self-registering smart pointers (GC handles) for all GC pointers. This registering happens at runtime, so it's a performance hit compared to systems where this information is generated at compile time (or JIT time).
The cost is fairly negligible. It can be quite lower than that of boost::shared_ptr, for example. Also, it's not like operations on gc pointers are performance critical.
Mathias Gaunard:
Sebastian Redl wrote:
and modify them. Conservative GCs do not know this. But precise ones do. And precise garbage collection can be implemented in C++ just fine. Yes, but only if you use special self-registering smart pointers (GC handles) for all GC pointers. This registering happens at runtime, so it's a performance hit compared to systems where this information is generated at compile time (or JIT time).
The cost is fairly negligible. It can be quite lower than that of boost::shared_ptr, for example.
I don't see how that can be.
Peter Dimov wrote:
The cost is fairly negligible. It can be quite lower than that of boost::shared_ptr, for example.
I don't see how that can be.
Here are some time comparisons for SGCL, for example: http://groups.google.com/group/comp.lang.c++.moderated/msg/583fb30d53275724
"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:gsqmcv$3ht$1@ger.gmane.org...
Sebastian Redl wrote:
Compacting (or otherwise moving) garbage collectors require detailed knowledge. They must know where the pointers to the moved objects are and modify them. Conservative GCs do not know this.
But precise ones do. And precise garbage collection can be implemented in C++ just fine.
Precise garbage collection can be implemented, but what about pointers stored in registers and temporaries? those can't be changed. __________ Information from ESET Smart Security, version of virus signature database 4033 (20090424) __________ The message was checked by ESET Smart Security. http://www.eset.com
"Sid Sacek" <ssacek@securewatch24.com> wrote in message news:85E89441B9FBAB4489AE98D0001A7FE902526F95@SW24MAIL.securewatch24.local...
My 2-cents.
My first penny: Although the thought of having memory-leaks become a concept of the past is pretty nifty to me by using a memory-managing programming language, the "garbage collectors" of today make no promises to the programmer about any other type of resource. Brute-force programming and RAII are our current protections against mismanaging these other resource types. If we end up using RAII in our apps because object destructors must be called in deterministic fashion, then the advantage of GC almost becomes irrelevant.
Except if you have cycles.
My second penny: There is one feature of an advanced GC that is super-beneficial to me however. The C++/CLI garbage collector has the ability to perform data compaction. Basically, when the GC activates, it removes the unused objects, and then fills in the vacated memory gaps with existing live objects, thus compressing memory usage. This ability can help you create applications that can run 24/7 ( basically forever ) without having any memory fragmentation. This to me is a better feature of the garbage collector. I personally don't know how the CLI engine performs this neat trick but it works, and the code generated by the compiler is crisp, compact and efficient. I don't know if there's a C++ based GC library out there that does this sort of thing.
No need for compaction, if you use pools.
Ok, one final cent: The GC's provided within programming languages are much more compelling than library-based ones. For me, the way they can be improved is by following these simple rules:
1) Eliminate all object memory that is no longer referenced ( standard feature ) 2) Have destructor functions be called in a deterministic manner ( finalizers optional ) 3) Have data compaction within the memory manager 4) Have the ability to manage other system resources as well 5) Provide the ability to manually manage specific resources ( for RTOS )
The "Garbage Collector" should be ideally renamed to "Resource Manager". Until these features mentioned above are given to me by a single language infrastructure, I believe I will be forced to resort to RAII as my most-trusted tool.
Well, in some situations even a library gc solution is better than nothing. __________ Information from ESET Smart Security, version of virus signature database 4033 (20090424) __________ The message was checked by ESET Smart Security. http://www.eset.com
Kasra skrev:
the gc::collect(), collects the memory as well as calling the destructor for non-destructed objects.
with the added caveat that it cannot guarantee to call the destructor for all otherwise "dead" objects. -Thorsten
participants (7)
-
Achilleas Margaritis -
Kasra -
Mathias Gaunard -
Peter Dimov -
Sebastian Redl -
Sid Sacek -
Thorsten Ottosen