[webkit-dev] WebKit memory management?

[Maciej Stachowiak]

Hi Chris,

On Jun 4, 2008, at 2:37 PM, Chris Brichford wrote:
> I have two "clever" ideas, which might be bad ones, that would not  
> involve massive changes to the existing code:

Interesting ideas. It appears that both of these would impost runtime  
cost (since calls to allocator-related functions would always be  
indirect through a pointer), unlike the two proposals I made. They  
also seem to be geared towards switching the allocator at runtime  
(possibly even per--instance), which is something we're not really  
looking at here. The main issues we'd like to address are:

1) Overloading global operator new and delete can interfere with other  
C++ code in the same program, making FastMalloc unusable for some ports.

2) We'd like to have ways for ports to replace FastMalloc at compile- 
time, but this is blocked by #1. I will also note that Nokia in their  
S60 port made a conservative low-memory allocator that allows  
allocations to be strictly bounded, but this work has not been merged  
to WebKit trunk.


> 1) Have a global variable that points to context that code in the  
> platform layer ( including things like malloc, free, operator new,  
> and operator delete ) can use.  Then have a class that is  
> instantiated on the stack before any call in to WebKit.  The  
> constructor for this class would copy the value of the global into a  
> member variable and set the global variable to point to the correct  
> context.  The destructor for this class would restore the previous  
> value of the global variable store in the member variable.

This proposal in particular seems like it still involves overloading  
global operator new and operator delete, which I think still creates a  
problem for linking with non-WebKit C++ code.

>
> 2) Use llvm ( http://llvm.org/) to create a C++ compiler that  
> compiles WebKit into a C or C++ program  ( you could also directly  
> generate machine code ) where every function ( including class  
> methods ) in webkit has an addition argument that points to the  
> "global" state.  The generated code would reference all global state  
> ( including static variables in classes and function ) relative to  
> this additional argument.  The client of webkit would have to  
> allocate a buffer large enough to contain this global state ( the  
> compiler would have to figure out how big the buffer needed to be )  
> and pass it into all WebKit entry points.  You'd be able to have  
> multiple copies of WebKit's global state in the same process.  You'd  
> have to hooks you need to destroy an instance of WebKit such that  
> you know all resources given to WebKit have been destroyed.  Similar  
> to the way an OS can tear down a process and reclaim an resources  
> give to that process.

Adding an extra parameter to every function would be a pretty big  
runtime hit, and source-to-source translation at build time is, I  
think, not so great for debuggability.

I'm thinking we'll probably have to bite the bullet and make some sort  
of pervasive code change to use our custom allocator in a sound way.  
It's unfortunate but I think the semantics of C++ force our hand.

Regards,
Maciej