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

[Stephan Assmus]

On 2010-02-21 at 13:14:59 [+0100], Mike Marchywka <marchywka at hotmail.com> 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.

Best regards,
-Stephan