[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 #36 from darin at apple.com  2008-11-24 09:24 PDT -------
(In reply to comment #35)
> If I inherit Rep from FastAllocBase it'll be no longer a POD and it can't be
> initalized with a C-style initializer list. (causes compile error)
> Should I add new/delete member functions to Rep or use fastNew/fastDelete?

Probably fastNew/fastDelete. If we wanted to add new/delete member functions, I
think we'd want to do it with a macro, not writing it by hand.

> Okay. I'll inherit ParserRefCounted. I didn't do this because there are some
> classes which inherited from ParserRefCounted but not constructed by new.

I think we can be a bit liberal about adding FastAllocBase as a base class for
various classes even if they aren't being used with new/delete. I don't think
the inheritance will do any harm.

> Okay, but how far up? There are a lot of classes which are inherited from (for
> example) Noncopyable but only a part of them instantiated with "new". And what
> can we do when the inheritance is private?

Currently we inherit from Noncopyable privately because there's no difference
between inheriting it privately and publicly. I think it would be fine to add
FastAllocBase as a base class for Noncopyable, just for convenience, and then
change inheritance of Noncopyable to be public inheritance -- it wasn't
important to inherit from it privately, and it's reasonable to change it.

> We've only tried this under linux-qt port. For the next version we need to
> modify the build system just for QtLauncher.

We'll want a version of this patch that tries to make all ports work, even if
it's not tested with all of them. I suggest making a small patch that
concentrates on the build issues of adding new source files and getting them
compiled in all ports, before doing a larger patch that tries to adopt this
class in all the relevant places.

It's easier to get things right if we do things in smaller pieces.

In particular, you want a small, easy-to-review patch that will exercise the
issues. For example, a patch that adds the new files and adds one use of each
aspect of the header in WebCore as well as in JavaScriptCore would be a good
idea. Then a larger patch that simply adopts the mechanism more widely.


-- 
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.