2009/9/16 SteveC <[email protected]> > > Now, I expect this is naive of me, but I notice there is lots of > static data in the codebase. if I were to refactor this into some kind > of 'GlobalContext' class, could I not simply instantiate multiple of > those GlobalContexts without them interfering with each other? Or is > there funky stuff to do with thread local storage or something else > that would make this fail? >
Basically I think that would work and would probably be a good idea. It's hard to say what the performance hit would be but we think it might be minimal. The generated code would be basically unchanged. I don't think you should underestimate the work involved: There are a lot of static variables scattered around. One idea that has been bandied around in the V8 team is to change the API minimally by adding a GlobalContext parameter to the V8::Locker constructor. So when you lock V8 you tell it which GlobalContext you want to use. The locker writes the GlobalContext into the operating system provided thread local storage (not to be confused with V8s ThreadLocal stuff which is completely different and arguably a misuse of the term - mea culpa!). Thread local storage tends to be very fast so it's not unrealistic (we think) to get the GlobalContext where we need it (pretty much everywhere!). The model provided by this is that you can have several GlobalContexts or Isolates and they share nothing with each other. The memory use is basically multiplied by the number of GlobalContexts you want to have. For each GlobalContext you can have 1 or more threads, just like you can now with the one implicit GlobalContext. (Probably the normal way to use it would be to have one GlobalContext per physical CPU.) A V8 thread can't move between GlobalContexts. Communication between JS programs running in different GlobalContexts would have to be done in C++. There can be more than one Context in a GlobalContext, but a Context is bound to one GlobalContext. On the plus side, the VM doesn't get much more complicated, there are still no difficult-to-debug race conditions between threads and it shouldn't be noticably slower for the case we really care about: Chromium. The first step http://images.google.com/images?q=first+step+is+doozie would be to make a single GlobalContext, put its address in thread local storage and measure how much that slowed things down. Patches welcome, as we like to say. :-) -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
