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=newObjectFoobar( ?? );
Barfoo* myBarfoo=newObjectBarfoo( ?? );
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 'newObjectint' and
instead of 'new char[32]' you would say 'newArraychar(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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
