[webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore

Gavin Peters (蓋文彼德斯) gavinp at chromium.org
Thu Oct 6 10:11:51 PDT 2011


Dan,

You're right.  I'm adding #if PLATFORM(CHROMIUM) to this change shortly.

- Gavin

On 6 October 2011 13:07, Dan Bernstein <mitz at apple.com> wrote:

>
> On Oct 6, 2011, at 9:40 AM, gavinp at chromium.org wrote:
>
>   Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 => 96819)
>
> --- trunk/Source/WebCore/dom/ScriptElement.h	2011-10-06 16:37:35 UTC (rev 96818)
> +++ trunk/Source/WebCore/dom/ScriptElement.h	2011-10-06 16:40:47 UTC (rev 96819)@@ -113,6 +113,14 @@       ZeroedInStopLoadRequest,       ZeroedInNotifyFinished,     } m_cachedScriptState;+
> +    // We grab a backtrace when we zero m_cachedScript, so that at later crashes
> +    // we'll have a debuggable stack.
> +    enum {
> +        MaxBacktraceSize = 32
> +    };
> +    int m_backtraceSize;
> +    void* m_backtrace[MaxBacktraceSize]; };
>
>
> This appears to increase the size of each ScriptElement instance by 256
> bytes. I don’t know how bad a performance hit this is in real-world use, but
> it is most certainly not something all vendors would like to include in
> their releases. The way this change was made, however, it is almost
> inevitable that a vendor would end up unknowingly shipping this performance
> regression. This change was made on trunk, it is unconditionally compiled
> in, and there is nothing obvious tracking undoing this change.
>
> I think this is the wrong way to incorporate diagnostic code into WebKit.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111006/a7d1d7f7/attachment.html>


More information about the webkit-dev mailing list