<?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: failure is not an option</title>
	<atom:link href="http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/feed/" rel="self" type="application/rss+xml" />
	<link>http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/</link>
	<description>noise from signal</description>
	<lastBuildDate>Thu, 10 Nov 2011 07:05:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: VanillaMozilla</title>
		<link>http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/comment-page-1/#comment-139186</link>
		<dc:creator>VanillaMozilla</dc:creator>
		<pubDate>Fri, 18 Apr 2008 13:50:14 +0000</pubDate>
		<guid isPermaLink="false">http://shaver.off.net/diary/?p=3891#comment-139186</guid>
		<description>&lt;p&gt;Exploiting a null pointer?  I really don&#039;t understand how this can still happen in the 21st century.  It&#039;s really time for computer languages to be strongly typed, to make sure null pointers really are null, and never to dereference null pointers.  This should NEVER be left up to the programmer.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Exploiting a null pointer?  I really don&#8217;t understand how this can still happen in the 21st century.  It&#8217;s really time for computer languages to be strongly typed, to make sure null pointers really are null, and never to dereference null pointers.  This should NEVER be left up to the programmer.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Watt</title>
		<link>http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/comment-page-1/#comment-139179</link>
		<dc:creator>Jonathan Watt</dc:creator>
		<pubDate>Thu, 17 Apr 2008 09:37:58 +0000</pubDate>
		<guid isPermaLink="false">http://shaver.off.net/diary/?p=3891#comment-139179</guid>
		<description>&lt;p&gt;OOM may basically be a hard failure today for small allocations, but those are less likely to fail. For the more high risk, larger allocations, I think we probably do a good job of checking and are much less likely to hard fail. I&#039;m glad to hear we&#039;ll at least still be able to still handle these points gracefully. ;-)&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>OOM may basically be a hard failure today for small allocations, but those are less likely to fail. For the more high risk, larger allocations, I think we probably do a good job of checking and are much less likely to hard fail. I&#8217;m glad to hear we&#8217;ll at least still be able to still handle these points gracefully. ;-)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: shaver</title>
		<link>http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/comment-page-1/#comment-139178</link>
		<dc:creator>shaver</dc:creator>
		<pubDate>Thu, 17 Apr 2008 08:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://shaver.off.net/diary/?p=3891#comment-139178</guid>
		<description>&lt;p&gt;We will be able to try to handle OOM gracefully, where it makes sense to do so and we can be very sure that we&#039;re going to do the right thing, which is why the jemalloc_canfail API has been requested in bug 427109.  OOM is basically a hard failure today, in that you&#039;re virtually certain to crash after really hitting OOM, because not everything checks returns well enough.  Whack-a-mole on those bugs is the wrong approach.&lt;/p&gt;

&lt;p&gt;For mobile, I think our strategy will more likely be &quot;detect low mem/quota limit, purge caches, try again&quot;, which can be done within an allocator wrapper.  Resource limiting is likely to be more effective for us, and safer, than trying to make all of our allocation paths handle &quot;unwind safely, hope enough gets freed, and resume&quot; -- especially if we want to be doing error reporting.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>We will be able to try to handle OOM gracefully, where it makes sense to do so and we can be very sure that we&#8217;re going to do the right thing, which is why the jemalloc_canfail API has been requested in bug 427109.  OOM is basically a hard failure today, in that you&#8217;re virtually certain to crash after really hitting OOM, because not everything checks returns well enough.  Whack-a-mole on those bugs is the wrong approach.</p>

<p>For mobile, I think our strategy will more likely be &#8220;detect low mem/quota limit, purge caches, try again&#8221;, which can be done within an allocator wrapper.  Resource limiting is likely to be more effective for us, and safer, than trying to make all of our allocation paths handle &#8220;unwind safely, hope enough gets freed, and resume&#8221; &#8212; especially if we want to be doing error reporting.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Watt</title>
		<link>http://shaver.off.net/diary/2008/04/16/failure-is-not-an-option/comment-page-1/#comment-139177</link>
		<dc:creator>Jonathan Watt</dc:creator>
		<pubDate>Thu, 17 Apr 2008 08:40:49 +0000</pubDate>
		<guid isPermaLink="false">http://shaver.off.net/diary/?p=3891#comment-139177</guid>
		<description>&lt;p&gt;So have we given up on the idea of failing gracefully and trying to carry on when we hit an OOM condition? Of course, you can never hope to get to a state where you will recover from all OOM conditions, but there are cases where I think we really want to try. SVG filters jump out as a good example. With our new mobile effort I&#039;d think handling OOM gracefully would be especially important.&lt;/p&gt;

&lt;p&gt;I&#039;d also think that making OOM a hard failure will allow any malicious Web page to crash the browser trivially.&lt;/p&gt;

&lt;p&gt;You mention up sides of switching to making OOM a hard failure, but I think there are down sides too.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>So have we given up on the idea of failing gracefully and trying to carry on when we hit an OOM condition? Of course, you can never hope to get to a state where you will recover from all OOM conditions, but there are cases where I think we really want to try. SVG filters jump out as a good example. With our new mobile effort I&#8217;d think handling OOM gracefully would be especially important.</p>

<p>I&#8217;d also think that making OOM a hard failure will allow any malicious Web page to crash the browser trivially.</p>

<p>You mention up sides of switching to making OOM a hard failure, but I think there are down sides too.</p>]]></content:encoded>
	</item>
</channel>
</rss>

