[webkit-dev] WebKit memory instrumentation

[Ilya Tikhonovsky]

It turns out that clang has good API for plugins and a simple plugin for
checking the instrumentation coverage contains ~200 loc.
Thus the first option looks useless.

Regards,
Tim.


On Wed, Jul 25, 2012 at 11:34 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky <yurys at chromium.org> wrote:
>
>
>
> On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky <yurys at chromium.org>
>> wrote:
>>
>>
>>
>> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak <mjs at apple.com>wrote:
>>
>>>
>>> On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky <yurys at chromium.org>
>>> wrote:
>>>
>>> *
>>>
>>> First option we consider is to define a class with the same set of
>>> fields as the instrumented one, then have a compile time assert that size
>>> of the reference class equals to the size of the instrumented one. See
>>> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more
>>> details.
>>>
>>> Pros: compile time error whenever size of an instrumented class changes
>>> with the appropriate modifications to the instrumentation function.
>>> Cons: it will require each committer to adjust the reference class and
>>> the instrumentation on any modification that affects size of the
>>> instrumented class. Changes that don't affect size of the class will go
>>> unnoticed.
>>> *
>>>
>>>
>>> What is the advantage of this approach compared to just using the sizeof
>>> operator on the relevant classes?
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>> Summing up sizeof type of each field and parent class and comparing it to
>> sizeof the class would do the same thing except that we would need
>> sometimes to manually handle alignment discrepancies on different platforms.
>>
>>
>> I'm not sure I understand the problem you are trying to solve. Isn't
>> sizeof on the class the correct answer? Why would you need to manually add
>> sizeof for the fields? You need sizes of objects referenced by pointer, but
>> that won't be affected by alignment issues.
>>
> We use sizeof to report *this size, after that we need to go through the
> fields and report referenced objects. The problem is that the set of fields
> may change eventually and break the instrumentation. The compile check
> should help developers not to forget to update the instrumentation and add
> traversal code for the new fields.
>
>
> It seems like the compile-time check would give false positives (if you
> add a non-pointer field) and false negatives (if you change the size of a
> buffer pointed to). The most obvious way to fix it would also be to update
> the size of the reference class and not do anything special about new
> pointers, which would be the wrong thing to do. So based on that, I'm not
> sure it's worth the cost. I think compile-time checks are more effective
> when the failure is more directly related to a developer mistake.
>
> Regards,
> Maciej
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120726/c92aaf3c/attachment.html>