[webkit-dev] are there any known or suspected memory issues with webkit?

[Mike Marchywka]

----------------------------------------
> Date: Sun, 21 Feb 2010 15:55:24 +0100
> From: superstippi at gmx.de
> To: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] are there any known or suspected memory issues with webkit?
>
>
> On 2010-02-21 at 13:14:59 [+0100], Mike Marchywka  wrote:
>> The reason I ask is because I thought there were some concerns about leaks
>> ( probably just stuff I saw skimming various google hits ) and I have
>> seen firefox and iceweasel light up my disk on very simple things ( like
>> typing stuff into forms). As I started looking through the code,
>> one of the first things I saw was something that looked like a hash table
>> of previously used pages- are there static "junk bins" of strong references
>> and stuff like that that could create memory leaks as they accumulate stuff
>> and never get cleaned or pruned?
>>
>> The other thing is that IMO ( opposing views welcome) memory
>> access patterns are often an unappreciated issue on many
>> architectures. The reason I reacted to the threading question as
>> I did is that it seems, again in my opinion on superficial/ anecdotal
>> analysis, that this approach often seems attractive but contains
>> a number of issues, among them those related to memory or
>> other resource allocations, that reduce the effectiveness even
>> with an ideal multi-CPU system I did make this point
>> before with reference to one speed-versus-threads graph
>> from IEEE,
>>
>> http://lists.boost.org/boost-users/2008/11/42263.php
>>
>>
>> Ceratinly " your mileage may vary" but resource
>> allocation and contention is probably already a big
>> deal and it may be a better place to look for
>> optimization. Launching a thread is a general idea
>> that can be used anywhere but digging into code may be
>> more effort and more specialized to a given task however.
>>
>> Thoughts?
>
> I don't understand the multi-threading nay-saying. Just as an L2 cache is a technology to speed up memory access, multi-core
> architecture is a way to increase processing speed of the CPU. Last time I looked, a -j2 build of WebKit runs almost twice as fast as a
> single job build on my Core2Duo system. So the technology obviously works. Just because improving cache locality is a way to improve
> the execution speed of a piece of software, it doesn't mean one should try to prevent efforts to make software explore the increased
> processing performance of additional CPU cores. And designing the software to make proper use of multi-threading and scale well is
> definitely not easy, or the cheap way out. Not at all.


Oh, it is not an attempt to discourage just not take something you happen
to have a lot of and put each one into a new thread esp when my
personal experiences seem to be related to memory depletion. The multi-core of course
does benefit from multiple threads, but it helps if they are doing things
that can play well with each other and not step over each other.
The OP on the related topic indiciated he hadn't looked much at details,
I'm just suggesting looking first. And, of course, once your disk light comes
on for VM things do get quite slow. Indeed, maybe the threading model could remove
some types of redundancy or thrashing but it won't do that if you just make a lot
of copies of things that all become slower. 

I guess from what I've seen personally on my machines the biggest problem
with browsing is VM and there are probably other issues with caching well before you
get there. I always expected browsing to be IO limited but clearly there are other limitations.



>
> Best regards,
> -Stephan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/