[webkit-dev] A proposal for "Platform Mechanisms"

Mike Marchywka marchywka at hotmail.com
Thu Jun 17 04:35:24 PDT 2010

> From: darin at apple.com
> Date: Wed, 16 Jun 2010 17:55:10 -0700
> To: andersca at apple.com
> CC: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] A proposal for "Platform Mechanisms"
> Sounds reasonable to me. We already follow pointers and use virtual functions for all these things, so I don’t see them adding a lot of overhead.

Just to reiterate the problem I keep seeing is that it appears that the virtuals are not the problem as
much as where the pointers finally point. That is, so ok you can inline all your pointer getters but if
someone collects a bunch of widget pointers and they point to different pages in VM and then they keep
accessing them in random orders, it is likely to create problems. This is my current concern since
I no longer seem to be able to fill out forms without the !#$!# disk light coming on for 10s of seconds at a time
and no chars being echoed in the meantime. 

While a ctor maybe an order zero thing, uses of the object will be fast or slow depending on what that does
to the memory situation. 

I'm not sure I have a specific suggestion that relates to this immediate issue other than "be aware of the 
potential and real concerns" and perhaps making getter users write inner loops that are coherent and 
simple and finally blocking them to preserve cache coherence, not just VM. ( and avoiiding runon sentences
leads to less coherences that is harder to read, you get the pointer LOL). 

> Would these Mechanism classes replace all the current Client classes? Would the mechanism objects be obtained once and cached globally? How is the initial PlatformMechanism object created?
> -- Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.

More information about the webkit-dev mailing list