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 <marchy...@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@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) _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
