<?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: Conservative stack scanning 101</title>
	<atom:link href="http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/</link>
	<description>where we're building a better SpiderMonkey from parts</description>
	<lastBuildDate>Tue, 30 Jun 2009 14:40:54 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joe Larson</title>
		<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/comment-page-1/#comment-18602</link>
		<dc:creator>Joe Larson</dc:creator>
		<pubDate>Thu, 07 Aug 2008 21:56:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/#comment-18602</guid>
		<description>I just found your site while looking at an old IOCCC entry your wrote called adventure. Then I saw this entry.

I love this stuff.

I was actually looking you up in reference to that IOCCC entry. If you would please e-mail me.</description>
		<content:encoded><![CDATA[<p>I just found your site while looking at an old IOCCC entry your wrote called adventure. Then I saw this entry.</p>
<p>I love this stuff.</p>
<p>I was actually looking you up in reference to that IOCCC entry. If you would please e-mail me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jorendorff</title>
		<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/comment-page-1/#comment-8</link>
		<dc:creator>jorendorff</dc:creator>
		<pubDate>Thu, 30 Aug 2007 15:37:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/#comment-8</guid>
		<description>Someone has!  Specifically, Leon Sha.  See &lt;a href=&quot;https://bugzilla.mozilla.org/show_bug.cgi?id=391333&quot; rel=&quot;nofollow&quot;&gt;bug 391333&lt;/a&gt;.  The patch for Solaris is attached.

I hate to disappoint, but it looks pretty easy:

#ifdef MMGC_SPARC
#define FLUSHWIN() asm(&quot;ta 3&quot;); 
#else
#define FLUSHWIN() 
#endif</description>
		<content:encoded><![CDATA[<p>Someone has!  Specifically, Leon Sha.  See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=391333" rel="nofollow">bug 391333</a>.  The patch for Solaris is attached.</p>
<p>I hate to disappoint, but it looks pretty easy:</p>
<p>#ifdef MMGC_SPARC<br />
#define FLUSHWIN() asm(&#8221;ta 3&#8243;);<br />
#else<br />
#define FLUSHWIN()<br />
#endif</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wes Garland</title>
		<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/comment-page-1/#comment-7</link>
		<dc:creator>Wes Garland</dc:creator>
		<pubDate>Thu, 30 Aug 2007 14:13:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/#comment-7</guid>
		<description>That&#039;s really quite clever. Thanks for the dissection!

Has this been ported to Solaris yet? The SPARC ABI uses a nifty sliding-register scheme for function argument passing, I&#039;d like to see how THAT works.</description>
		<content:encoded><![CDATA[<p>That&#8217;s really quite clever. Thanks for the dissection!</p>
<p>Has this been ported to Solaris yet? The SPARC ABI uses a nifty sliding-register scheme for function argument passing, I&#8217;d like to see how THAT works.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jorendorff</title>
		<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/comment-page-1/#comment-5</link>
		<dc:creator>jorendorff</dc:creator>
		<pubDate>Thu, 09 Aug 2007 19:42:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/#comment-5</guid>
		<description>Anders,

Yes, errors of both kinds (incorrectly marking something that isn&#039;t really reachable, and incorrectly collecting something that is) are possible.  Even C can&#039;t create a rock it can&#039;t lift, or (which is the moral equivalent) a GC that it can&#039;t fool.

For another way to fool MMgc, open MMgc/GC.h and search for GCHiddenPointer.  :)

MMgc actually does detect the &quot;disguised&quot; reference in the specific case you describe.  However, see &lt;a href=&quot;https://bugzilla.mozilla.org/show_bug.cgi?id=388070&quot; rel=&quot;nofollow&quot;&gt;bug 388070&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Anders,</p>
<p>Yes, errors of both kinds (incorrectly marking something that isn&#8217;t really reachable, and incorrectly collecting something that is) are possible.  Even C can&#8217;t create a rock it can&#8217;t lift, or (which is the moral equivalent) a GC that it can&#8217;t fool.</p>
<p>For another way to fool MMgc, open MMgc/GC.h and search for GCHiddenPointer.  <img src='http://blog.mozilla.com/jorendorff/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>MMgc actually does detect the &#8220;disguised&#8221; reference in the specific case you describe.  However, see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=388070" rel="nofollow">bug 388070</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anders</title>
		<link>http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/comment-page-1/#comment-4</link>
		<dc:creator>Anders</dc:creator>
		<pubDate>Thu, 09 Aug 2007 18:52:04 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.com/jorendorff/2007/08/09/conservative-stack-scanning-101/#comment-4</guid>
		<description>&gt; C can do anything

Not quite (please correct me if I&#039;m wrong). That&#039;s where the &quot;conservative&quot; part comes in. Since C don&#039;t really know what is on the stack or in the heap (i.e. what data types), it just errs on the safe side and assumes everything (well maybe only the n-byte aligned?) is pointers. So even if it sees a string it will treat it as a pointer and if the characters of that string can be interpreted as a pointer to a block of memory that the allocator have allocated, that block will be marked as referenced. But (a) this probably doesn&#039;t happen very often in practice, since the character sequence (or the integer or floating point number) must be interpreted as a pointer that point exactly to the start of an allocated block and (b) even if it did, the worst thing that could happen is that a block of memory wouldn&#039;t be collected immediately.

But this also means that another way of fooling the GC is by instead of keeping a pointer the the start of an allocated block, holding a pointer to the second byte (or any other place relative to the allocated block). While your code might know how to access the block based on the offset into the block, the GC probably isn&#039;t conservative enough to recognize the &quot;disguised&quot; reference and will collect and free the referenced block in error.</description>
		<content:encoded><![CDATA[<p>&gt; C can do anything</p>
<p>Not quite (please correct me if I&#8217;m wrong). That&#8217;s where the &#8220;conservative&#8221; part comes in. Since C don&#8217;t really know what is on the stack or in the heap (i.e. what data types), it just errs on the safe side and assumes everything (well maybe only the n-byte aligned?) is pointers. So even if it sees a string it will treat it as a pointer and if the characters of that string can be interpreted as a pointer to a block of memory that the allocator have allocated, that block will be marked as referenced. But (a) this probably doesn&#8217;t happen very often in practice, since the character sequence (or the integer or floating point number) must be interpreted as a pointer that point exactly to the start of an allocated block and (b) even if it did, the worst thing that could happen is that a block of memory wouldn&#8217;t be collected immediately.</p>
<p>But this also means that another way of fooling the GC is by instead of keeping a pointer the the start of an allocated block, holding a pointer to the second byte (or any other place relative to the allocated block). While your code might know how to access the block based on the offset into the block, the GC probably isn&#8217;t conservative enough to recognize the &#8220;disguised&#8221; reference and will collect and free the referenced block in error.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
