"Frank Chang" <Fr**********@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
Chris, If this post appears twice it is because my browser crashed. I
read your link http://www.ieec.com.gclist/GC-faq.html . This article
contains a section, Thread Support, which discusees safe-points.
However, the thread support section does not contain a discussion about
how the GC-List unmanaged C++ garbage collection policy handles
releasing the memory allocated by multiple threads back to the
operating system after the threads have finished their tasks. Even in
managed C++(.NET), I believe it may be true that the memory released by
threads is released to the .NET "VM" rather than the operating system.
I scanned the link concerning Java garbage collection which you
provided but I am not sure if Arvind can apply those same solutions to
unmanaged C++ garbage collection.
I read Arvind's web page about his current research interests. It
is interesting to read. Evidently, Arvind has started two companies
since 2000. I just don't think it would be a good idea to start a
company built around an unmanaged C++ garbage collection framework.
The total revenues of this hypothetical company would be a lot less
than the cost of R&D required to build such a product. Also, it is
uncertain how the unmanaged C++ community react to such a product once
it were introduced. Thank you.
Hi Frank,
GC-list is rather a discussion/knowledge base than an actual implementation.
Releasing memory from the GC to the OS is implementation dependent and also
a philosophical question. It can be argued whether it is a good idea to
immediately return memory to the OS pool, but in IMHO for most applications
it is not such a hot idea. If you have a lot of short-lived threads it will
pay off to keep control over the memory, however for long lived threads the
situation can be different. AFAIK many GC implementations delay the release
to the OS as long as possible.
I also think the .NET handles it that way but you might check Mike Zintels
blog for this (
http://blogs.msdn.com/mikezintel/default.aspx).
It actually makes sens that the .NET VM is the instance taking care of the
memory for the whole .NET framework as it allows for better control. I
actually would be very cautious investing my money in the R&D for a new
unmanaged C++ GC as there are quite sophisticated open source
implementations already available, but this is a rather personal opinion and
I certainly do not want to discourage anybody from doing this. There is
certainly large room for improvement on the technical side, but I have my
reservations regarding the economical aspects of such an undertaking.
Anyway, you normally can apply the basic ideas of the Java GC also to an
unmanaged C++ GC, but naturally you'll run into big difference regarding the
interfacing. In Java (and C#) the memory management is done mostly under the
hood, whereas in unmanaged C++ it will be the developer who will have to
interface with the GC at some point or the other.
HTH
Chris