Hi, > 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
That sounds nice and simple from the API point of view, and would also minimise the amount of function-signature refactoring required. I've actually done something a bit similar to the whole 'TLS for storing GlobalContexts' idea in the rest of my app, so at least I should be familiar with the general pattern. > 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. Hehe; well I think my very first step is to do a quick evaluation of the amount of static variables I would have to mess with :-) But yes, some profiling would be a good start, since of course you guys won't want to introduce any performance issues just to support functionality not needed by Chrome. Even if the TLS has a noticeable cost, we might still be able to have a #define switch to change between the full TLS thing and a simpler version, where there is one static GlobalContext, which would surely cost nothing to access :-) > Patches welcome, as we like to say. :-) Excellent! That would save any worrying about forking/maintainance etc for me :-) The choice for me is either mess with V8, or try to get TraceMonkey going. I will go and look see how much work there might be in adding the GlobalContext idea to V8. If its practical, I will very seriously look at doing this work. Best Regards, Steve. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
