Stephen, Please do not underestimate the effort involved here. In heap.h alone there are about 150 statics which you would need to move to an isolate along with the other widely distributed statics in the other C++ classes. Many of the static definitions are hidden in massive macros, so a simple count of "static" is going to give you inaccurate results.
As far as code-style and other things to consider please take a look at http://code.google.com/p/v8/wiki/Contributing. In general bigger patches are harder to review. So a set of smaller patches is a.) easier to review, b.) faster to assess if you are on the right track and c.) gives you early indication about the overhead for accessing all current static data through thread local storage. Also we try to not have too many different #ifdef in the code because that reduces maintainability, increases testing complexity and complicates matters when using the same pre-built library in different settings. As an example, a Linux distribution might only have one libv8.so, should this be the version using isolate support or not? Having said that it means that the TLS based statics should have a negligible effect on V8 performance if they are supposed to be successful. Cheers, -Ivan On Thu, Sep 17, 2009 at 11:17, Stephen Clibbery <[email protected]> wrote: > > Hi, > > Well, I've had a look at the codebase, and I reckon there are just > over three hundred static variables that would need to go into a > Global Context. I'm not saying I'm definitely going to do this yet, > but if I do have a go, I have a few practical questions: > > * What's the best way to measure any possible performance regressions? > * I can only develop for Windows, but a TLS-based solution will likely > need a little porting to other platforms; is this ok? > * Are there any published code-style guidelines for V8? > * Should I try to land one big patch with all the changes, or find a > way to do it more incrementally? > * Anything else I should know? :-) > > Best Regards, > Steve > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
