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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
