[webkit-dev] Checking allocation failures [was: Re: Naked new considered harmful]

[Sriram Neelakandan]

Hi all,

I am still a newbie in this ocenaous wekbit  ... here are some
thoughts from me.. please correct me if i have misunderstood some
thing;

Talking on the same lines of Resource allocations.. I have seen
already snips of code that handle Large Resource allocations
gracefully. For instance i think the ImageReosource has a check on
maximum decoded image size..But that just applies to a single image
being decoded;
What webkit may need is something like maximum amount of memory
available for all Image Resources in a page.. and when the limit is
hit inform the Client/embedder of the same.
So basically in this case the page can get gracefully degraded and the
user can be informed of the same; I think some other stuff like CSS
can also be gracefully handled

But Now lets say there is a cap for maximum JS memory and we run out
of it some reason; then it would be safe to inform the user and unload
the page itself;

I have seen lot of cache storage code that is already checking for
resource object sizes (including decoded sizes).. I think this may be
a worthy to try

On 8/26/10, Mike Marchywka <marchywka at hotmail.com> wrote:
>
>
>> >>> this reminds me that I've always been wondering about checks for
>> >>> allocation
>> >>> failure in WebCore (versus concerns about leaks). A plain call to new
>> >>> may
>> >>> throw an std::bad_alloc exception. If this is not considered, it may
>> >>> leave
>> >>> objects in an invalid state, even when using objects such as RefPtr to
>> >>> wrap
>> >>> arround allocations. I don't remember any specific place in the
>> >>> WebCore
>> >>> code
>> >>> where it would be a problem, I just don't remember seeing any code
>> >>> that
>> >>> deals with allocation failures. Is this a design choice somehow? If
>> >>> so,
>> >>> is
>> >>> there some online documentation/discussion about it? (Tried to google
>> >>> it
>> >>> but
>> >>> found nothing...)
>> >>
>> >> Failed allocations in WebKit call CRASH(). This prevents us from
>> >> ending up in an inconsistent state.
>> >
>> > Ok, but WebKit is used on devices where allocation failure is somewhat
>> > of a
>> > realistic possibility, no? Wouldn't it be desirable to handle such a
>> > situation gracefully? (I.e. display of an error message when trying to
>> > open
>> > one more tab rather than crashing the entire browser, for example.)
>> > Hopefully I am not missing something obvious.
>>
>> Dunno. The crash-on-allocation failure assumption is baked into lots
>> of lines of code.
>>
>> We do have a tryFastMalloc() path that returns NULL on allocation
>> failure instead of crashing. It's used in some pieces of code that are
>> carefully written to handle an allocation failure gracefully.
>> However, this is rare.
>>
>> In general it's very difficult to recover from an allocation failure in
>> an arbitrary piece of code with an arbitrary callstack.
>>
>> - James
>>
>
> ( hotmail is still having all kinds of problems, doesn't seem to like text
> or a modem connection, sorry for eidting slop ).
>
> I guess this relates to many earlier comments including that issue with the
> linker reporting a memory problem LOL. I'm just thinking out loud since no
> one on thread
> seems to have a lot of conviction so far.
> You could probably make a list of reasons why an allocation could fail:
> 1) the app is shutting down or OS is shutting down,
> 2) what you are trying todo is too big for the platform,
> 3) someone else has the resources you need for a tolerable or intolerable
> time,
> 4) you have bad data and calculated a size based on absurd numbers.
> 5) Algorithm failure, you have reasonable data but either code or algorirthm
> has a bug or impractical way of handling the data.
>
> Hopefully, you aren't just allocating memory on the spur of the moment," oh
> look I need more memory how about that," and could maybe even consider
> planning ahead. Presumably this helps validate your data, or at least sanity
> check it, maybe if you have 1<<30( hotmail somtimes tries to interpret gt, I
> mean of course 2^30 LOL if the
> shift operator got mangled )
> and 1<<30 they really are not the width and height of an image or one
> you could practically show on the platform.
>
> I guess first it would help to make sure the platform API's give you
> abilities to
> determine what makes sense for the platform and some introspective API gave
> you some ability to understand who has what and why. Then more use of
> strategy
> type classes or planners could let you estimate memory needs and even
> allocate
> things together to improve coherence.
>
> It can be hard to clean up a partially created thing like a tab but if you
> group the memory allocations at a logical unit of some kind it would be a
> lot
> easier to just give up without trying. It is probably possible to warn the
> user
> too, " you have too much open" just as some browsers give the " a script is
> causing
> your computer to run slowly" message.
>
>
> While this is a bit grandiose I'm just trying to focus conversation and
> relate
> it to my fixation on memory coherence and resource usage.
>
>
>
>
>
>
>>
>> Adam 		 	   		
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>


-- 
Sriram Neelakandan
Author - Embedded Linux System Design And Development
(http://tinyurl.com/2doosu)