I have two "clever" ideas, which might be bad ones, that would not involve massive changes to the existing code: 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. 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. Chris.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, June 04, 2008 12:49 PM To: Paul Pedriana Cc: WebKit-Dev; Mark Rowe Subject: Re: [webkit-dev] WebKit memory management? . . . . I can think of two possible solutions: 1) Instead of overloading the global operator new and delete, have a FastAllocated base class that overloads the class operator new and delete, and make every class in WebCore and JavaScriptCore inherit from it; for non-class types, avoid using new, delete, new[] or delete[] (perhaps template functions could be provided). The downside is that I can't think of an easy way to then flag mistaken use of new/delete on primitive types, or forgetting to inherit from the FastAllocated base class. Then again, we don't try to flag mistaken use of malloc() instead of fastMalloc() and that has been ok. 2) Require allocation to happen in some way other than "new" and "delete", for instance always with template functions. Then perhaps we could use #defines to make any actual use of "new" and "delete" an error. Either of these would be a large change to the source, especially #2 (#1 only needs to affect classes with no other subclass and the few places we use new[] on non-class types to make arrays). Perhaps someone else has a more clever idea. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
