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

[Leo Meyerovich]

Mike Marchywka wrote:
>
>
>
>
>
>
>
> ----------------------------------------
>   
>> 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. 
>
>   

In my experience parallelizing browser algorithms on various hardware 
configs, much of the benefit of exploiting new architectures is often 
just getting more cache. Even if you're not CPU bound, as new multicore 
hardware may work funny at the L1/L2 level, redesigning algorithms to 
work better at this level not only improves sequential performance but 
also essentially multiplies how much local cache you have.

There don't seem to be any technical questions on this thread, so I'll 
stop proselytizing ;-)

[Obviously why browsers go way beyond L2/L3 is a concern as is the 
prefetching technology, but those are somewhat orthogonal concerns to 
speeding up the CPU or arguably bandwidth bound bottlenecks like painting.]

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