[webkit-dev] WebKit memory management?
mjs at apple.com
Wed Jun 4 16:00:26 PDT 2008
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.
More information about the webkit-dev