You are correct, though non-PODs are intended to go through the
base-case operator new, whereby this wouldn't apply. The newObject
template would have applicability only to PODs or even just built in
types like int/char. If somehow it was deemed that this means was
needed for non-PODs, the typical solution is to use a macro, as in:
#define newObject(Type) new(fastMalloc(sizeof(Type)) Type
This has some advantages beyond argument passing over the template
solution. We've used this approach fairly successfully on a large scale
at my company.
Paul
Hi,
I just wonder how you can pass arguments to your new operator when they are
mandatory (no default constructor), in the following case:
class Foobar{
public:
Foobar(int a,char* b);
};
class Barfoo{
public:
Barfoo(char* a);
}
Foobar* myFoobar=newObject<Foobar>( ?????? );
Barfoo* myBarfoo=newObject<Barfoo>( ?????? );
Reading your patch, I don't think this testcase will work... will it?
Fred
Le Tuesday 16 September 2008 à 20:28, Paul Pedriana a écrit :
>> I'm curious to see the patch (just to give an idea how
>> big the changes would be). Do you have it somewhere?
The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
I don't think this is a terribly difficult thing to implement (though
I don't mean to imply that it's trivial either). It might take a couple
iterations to make sure all instances are handled, though. I searched
the code and found a couple thousand instances of the keyword 'new',
though most of those would fall under the case of the base class operator.
>> Ah I see now. So you want to isolate the malloc from
>> WebKit module. Furthermore, you want to be able to
>> "kill" WebKit *only* when something weird happens,
>> am I correct?
I want to be able to shut down WebKit at any time, and possibly restart it.
If WebKit is used as a library within an application instead of being the
application itself, then you want to initialize it when needed, but when
it's
no longer needed then you want to shut it down. Think of computer games
like Grand Theft Auto whereby you are a character walking around the
world investigating something; and your character walks up to a computer
in the game and uses it to connect to the real web (using an embedded
WebKit)
to search for live-generated info for a while. When the character shuts off
the virtual computer, the game needs the resources of that computer to
go away, as the game needs to recover the RAM for the next thing the user
does. It significantly improves heap fragmentation of that WebKit instance
ran in a single contiguous block of memory such that when it went away
there is a nice big clean space left over.
That being said, your original case of killing WebKit when something weird
happens is also a practical use case. Such a thing might in fact be memory
exhaustion due to fragmentation.
Paul
The primary benefit of being able to override operator new is to be able
to redirect all allocations for a library to a user-specified heap. With
global operator new, allocated WebKit memory is mixed in with the rest
of the application memory and there is no practical way to tell them
apart or sequester them. This makes it impossible to correctly shut down
WebKit at runtime, since you don't know where its memory is. A side
benefit related to this is that this allows for better memory metrics
gathering.
Ah I see now. So you want to isolate the malloc from WebKit module.
Furthermore, you want to be able to "kill" WebKit *only* when something
weird happens, am I correct?
The proposal provides for a base class that overrides global operator
new. So any allocated classes use the same syntax as usual. Most of the
source code would fall under this.
Yes, that is true.
For the case of non-class-based memory allocations (e.g. raw char
array), the proposal provides a newObject and newArray template
function. So instead of 'new int' you would way 'newObject<int>' and
instead of 'new char[32]' you would say 'newArray<char>(32)'. However,
there is an alternative approach which is to provide a custom operator
new type, like so:
struct WTF{};
void* operator new(size_t size, WTF);
and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
conventional solution to namespacing operator new, where the C++
standard doesn't allow for operator new being in a C++ namespace.
Perhaps this syntax is preferable. This can be #defined to simply newWTF
if desired, then it is practically identical to existing global new
syntax.
FWIW, I have been testing the proposed patch in my copy and so far it
has been fine, but that of course includes only my uses.
I'm curious to see the patch (just to give an idea how big the changes
would be). Do you have it somewhere?
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
|
