[webkit-dev] WebKit memory management?

[zaheer ahmad]

>> This makes it impossible to correctly shut down WebKit at runtime
on this topic, i see that few singleton/global objects
(ResourceHandleManager, Cache, allPages(Page.cpp) ) and possibly more are
not getting destructed when webview is closed on the linux/gtk port. I dont
know if this is an intended behavior or a bug, but this could be an issue in
cases where you want to do a shut down only of webkit library. comments?

thanks,
Zaheer

On Wed, Sep 17, 2008 at 12:58 AM, Paul Pedriana <ppedriana at gmail.com> wrote:

>  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 listwebkit-dev at lists.webkit.orghttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080917/bc2671ba/attachment.html