[Webkit-unassigned] [Bug 20422] Patch to allow custom memory allocation control

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20422





------- Comment #37 from ppedriana at gmail.com  2008-12-01 22:33 PDT -------
I'm working on a revision of the allocator code that addresses Darin's comments
in https://bugs.webkit.org/show_bug.cgi?id=20422#c34. It might be useful to
know that I have been working on the allocator implementation and its unit
test, while Zoltan has been working on the application code to use it.

In the meantime, I have a response to three items.

    >> -  do_free(ptr);
    >> +  free(ptr);
    >>  }

    > Do you really need to change this?

I believe, the former behavior is a bug, as it bypasses the InvokeDeleteHook
mechanism. cfree is a sibling to free and a complement to calloc. Without the
above fix, a call to calloc would result in a call to InvokeNewHook, but the
eventual call to cfree would never call the InvokeDeleteHook.

    >>    if (new_size == 0) {
    >> -#ifndef WTF_CHANGES
    >> -    MallocHook::InvokeDeleteHook(old_ptr);
    >> -#endif
    >>      free(old_ptr);
    >>      return NULL;
    >>    }

    > I don't understand what the value is of removing InvokeDeleteHook here.

The InvokeDeleteHook call is redundant and is called again within free. Aside
from being less efficient, it complicates the user's implementation
requirements and makes it harder to do validation since the user would have to
keep track of pointers being 'double-deleted'.

If for some reason people want to keep the existing (IMO buggy) behavior, then
I can undo the above.

    >> I don't understand how you can store both the array size and
    >> the validation type in the same place; "p" and "a.size" both point
    >> to the same address. Maybe I'm missing something obvious here.

They aren't stored in the same place. The validation type is stored prior
in memory to the array size. First the validation type is written in some
reserved prefix bytes, then the array size is written in its own reserved
prefix bytes. The array code doesn't care about the location of the
validation type bytes. The unit tests exercise this and execute OK, FWIW.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.