<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to GC in C(++)</title>
	<atom:link href="http://blog.affien.com/archives/2005/04/03/how-to-gc-in-c/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.affien.com/archives/2005/04/03/how-to-gc-in-c/</link>
	<description>A few thoughts</description>
	<lastBuildDate>Mon, 23 Aug 2010 14:18:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Kaja</title>
		<link>http://blog.affien.com/archives/2005/04/03/how-to-gc-in-c/comment-page-1/#comment-352</link>
		<dc:creator>Kaja</dc:creator>
		<pubDate>Mon, 04 Apr 2005 01:45:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.w-nz.com/archives/2005/04/03/how-to-gc-in-c/#comment-352</guid>
		<description>Nice intro article to garbage collection.

The garbage collector is what has continually forced me to rewrite PX again and again.  On this current build, the GC was the first part of the VM that I built.

Fragmentation only goes away on a managed &quot;heap&quot; in the technique you described (known as &quot;mark and compact&quot;).  Most other GC uses &quot;mark and sweep&quot; which doesn&#039;t allow moving of objects.  This does still have some fragmentation however a good algorithm can reduce fragmentation greatly and it doesn&#039;t require the amount of overhead needed for &quot;mark and compact&quot;.

The trickiest part of &quot;mark and compact&quot; is updating all references to an object when an object moves.  The common answer is have a list (linked usually allow in PX, they&#039;re not &quot;linked&quot; together, will be more an array once i fix it) of &quot;handles&quot; that point to an object that be garbage collected.  And then, rather than using pointers to the objects is a member variable, you point to the handle, and then when the object is moved you update the handle pointer to the new location.  This way all references to an objects is updated with the changing of a single pointer.  This requires additional memory that needs to be there at all times (the handle is freed once the object is freed) but is the fastest way I know to do this.

The other way is to make a huge list of all objects that survive the garbage collection and their new locations in memory.  Then traverse memory again, updating each individual member  to point to the moved objects.  This allows the overhead to be only needed during the actual collection, but you have to traverse memory twice, which can be quite slow in large heaps.

Another tricky thing is keeping track of what objects are still considered &quot;active&quot;.  You need to maintain some sort of list that can be added to or automated from any part of your program that can create objects.

Just my 2 cents on GC and things that cause the PxVM&#039;s GC to take so long to build.  Hope this helps if you ever decide to build one.

(Maybe I should include different garabge collection techniques in my &quot;Algorithms&quot; tutorials.  Nothing too in depth just a general overview...)</description>
		<content:encoded><![CDATA[<p>Nice intro article to garbage collection.</p>
<p>The garbage collector is what has continually forced me to rewrite PX again and again.  On this current build, the GC was the first part of the VM that I built.</p>
<p>Fragmentation only goes away on a managed &#8220;heap&#8221; in the technique you described (known as &#8220;mark and compact&#8221;).  Most other GC uses &#8220;mark and sweep&#8221; which doesn&#8217;t allow moving of objects.  This does still have some fragmentation however a good algorithm can reduce fragmentation greatly and it doesn&#8217;t require the amount of overhead needed for &#8220;mark and compact&#8221;.</p>
<p>The trickiest part of &#8220;mark and compact&#8221; is updating all references to an object when an object moves.  The common answer is have a list (linked usually allow in PX, they&#8217;re not &#8220;linked&#8221; together, will be more an array once i fix it) of &#8220;handles&#8221; that point to an object that be garbage collected.  And then, rather than using pointers to the objects is a member variable, you point to the handle, and then when the object is moved you update the handle pointer to the new location.  This way all references to an objects is updated with the changing of a single pointer.  This requires additional memory that needs to be there at all times (the handle is freed once the object is freed) but is the fastest way I know to do this.</p>
<p>The other way is to make a huge list of all objects that survive the garbage collection and their new locations in memory.  Then traverse memory again, updating each individual member  to point to the moved objects.  This allows the overhead to be only needed during the actual collection, but you have to traverse memory twice, which can be quite slow in large heaps.</p>
<p>Another tricky thing is keeping track of what objects are still considered &#8220;active&#8221;.  You need to maintain some sort of list that can be added to or automated from any part of your program that can create objects.</p>
<p>Just my 2 cents on GC and things that cause the PxVM&#8217;s GC to take so long to build.  Hope this helps if you ever decide to build one.</p>
<p>(Maybe I should include different garabge collection techniques in my &#8220;Algorithms&#8221; tutorials.  Nothing too in depth just a general overview&#8230;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
