[webkit-dev] WebKit memory management?

[Paul Pedriana]

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