Comments on: Multithreaded Garbage Collection http://www.airs.com/blog/archives/196 Ian Lance Taylor Tue, 18 Nov 2008 21:44:16 +0000 http://wordpress.org/?v=1.5.2 Comment on Multithreaded Garbage Collection by: Ian Lance Taylor http://www.airs.com/blog/archives/196#comment-14065 Sun, 25 May 2008 16:44:20 +0000 http://www.airs.com/blog/archives/196#comment-14065 Jonathan: thanks for the link. They seem to be talking about concurrent garbage collection of interpreted Java. ncm: A program like gcc uses GC not because it doesn't use destructors, but because the lifetime of memory objects is uncertain, and there can be multiple pointers to a single memory object. Jonathan: thanks for the link. They seem to be talking about concurrent garbage collection of interpreted Java.

ncm: A program like gcc uses GC not because it doesn’t use destructors, but because the lifetime of memory objects is uncertain, and there can be multiple pointers to a single memory object.

]]> Comment on Multithreaded Garbage Collection by: ncm http://www.airs.com/blog/archives/196#comment-13933 Thu, 22 May 2008 19:22:13 +0000 http://www.airs.com/blog/archives/196#comment-13933 The GC proposal for C++ was withdrawn because it was dreadfully immature. There was lots of interest, in principle, but it was clear that there was no way it could be ready in time for C++0x. There was also lots of opposition, not helped by advocates' dismissive attitude toward problems, and spontaneously spurious statistics (90% and 99% figured prominently). Part of the problem, in my opinion, is that people who advocate built-in GC are chasing two opposed goals. One, the basis for the business of the proposal author, is rescuing buggy, leaky programs. The other is sound resource management. Everybody agrees, on paper, that GC is no substitute for running destructors, but a program that runs destructors gets vanishingly little benefit from built-in GC. A program that fails to run destructors leaks memory, but that's likely to be the least of its problems. The GC proposal for C++ was withdrawn because it was dreadfully immature. There was lots of interest, in principle, but it was clear that there was no way it could be ready in time for C++0x. There was also lots of opposition, not helped by advocates’ dismissive attitude toward problems, and spontaneously spurious statistics (90% and 99% figured prominently).

Part of the problem, in my opinion, is that people who advocate built-in GC are chasing two opposed goals. One, the basis for the business of the proposal author, is rescuing buggy, leaky programs. The other is sound resource management. Everybody agrees, on paper, that GC is no substitute for running destructors, but a program that runs destructors gets vanishingly little benefit from built-in GC. A program that fails to run destructors leaks memory, but that’s likely to be the least of its problems.

]]> Comment on Multithreaded Garbage Collection by: Jonathan http://www.airs.com/blog/archives/196#comment-13926 Thu, 22 May 2008 14:14:02 +0000 http://www.airs.com/blog/archives/196#comment-13926 I noticed this paper yesterday - it may (or may not) be of interest : Cell GC: Using the Cell Synergistic Processor as a Garbage Collection Coprocessor http://www.research.ibm.com/cell/papers/2008_vee_cellgc.pdf I noticed this paper yesterday - it may (or may not) be of interest : Cell GC: Using the Cell Synergistic Processor as a Garbage Collection Coprocessor http://www.research.ibm.com/cell/papers/2008_vee_cellgc.pdf

]]>