On Jun 5, 2006, at 7:49 AM, Geoffrey Garen wrote:

FYI, a static AtomicString would be a Bad Thing (TM) anyway, since it would require WebKit to have a static initialization routine for that string. Such a routine increases the start-up time and memory footprint of anything that links against WebKit, which includes just about everything that ships with OS X. (In fact, we have some open bugs about that.)

You can use a static AtomicString inside a function. These types of global variables are initialized the first time the function is called. As Geoff says, because of requirements for the WebKit framework on OS X, global variables outside functions with constructors are not allowed in JavaScriptCore, WebCore, or WebKit. That's why you'll see a lot of globals with, say, a HashMap* type instead of just a HashMap. -- Darin

On Jun 5, 2006, at 12:14 PM, Mike Emmel wrote:

the problem with global statics is technical and has to do with the order or lack thereof of the static constructors

I'm not sure what you mean. For our frameworks for Mac OS X we have a constraint for performance reasons, entirely separate from the static initialization order issue. Because of that constraint, the WebKit project rule is "no static initialization at all". Yes, there are some technical issues about doing global static initialization right. But in this project we avoid them since we don't have any for the above reason.

In this case one is missing and in any case order is never assured technically the static constructor may be on the wrong class. My opinion is you may want to fix the core classes to actually work correctly with global statics

I don't think we want to do this, again for performance reasons. We don't want to pay for a global variable fetch and a branch when creating each AtomicString to check to see if the global initialization has been done yet. Instead, we have chosen the approach of not using AtomicString until after the AtomicString::init () function is called. -- Darin

Well I finally looked into the file I was going to create the patch and what do I find in AtomicString.cpp #include "config.h" #if AVOID_STATIC_CONSTRUCTORS #define ATOMICSTRING_HIDE_GLOBALS 1 #endif So someone thought it should be optional. Of course as I pointed out earlier AtomicString is broken so changing this ifdef will break the build. Mike On 6/5/06, Mike Emmel <mike.emmel@gmail.com> wrote:

On 6/5/06, Darin Adler <darin@apple.com> wrote:

...

On Jun 5, 2006, at 12:14 PM, Mike Emmel wrote:

...

the problem with global statics is technical and has to do with the order or lack thereof of the static constructors

I'm not sure what you mean.

For our frameworks for Mac OS X we have a constraint for performance reasons, entirely separate from the static initialization order issue. Because of that constraint, the WebKit project rule is "no static initialization at all".

No problem.

...

Yes, there are some technical issues about doing global static initialization right. But in this project we avoid them since we don't have any for the above reason.

...

In this case one is missing and in any case order is never assured technically the static constructor may be on the wrong class. My opinion is you may want to fix the core classes to actually work correctly with global statics

I don't think we want to do this, again for performance reasons.

We don't want to pay for a global variable fetch and a branch when creating each AtomicString to check to see if the global initialization has been done yet. Instead, we have chosen the approach of not using AtomicString until after the AtomicString::init () function is called.

By moving the static variable to be lazy you have ensured this. My point is that at least for gcc you can use static constructors to initialize AtomicString::init could be called from one of those.

Agian I have no problem with all the reasons given to not make heavy use global static atomic string. I would argue that the reasons may not be valid for all possible ports of WebKit. If some one had a valid reason then it would at least intially be port specific.

I think its a bug in the implementation that atomic string cannot be used for static variables regardless of OSX and the use cases on osx. If its fixed the patch could even be ifdef'ed to not function on OSX to prevent static variable from sneaking into generic code.

I don't like basic stuff like AtomicString being broken its not a good thing. There is nothing wrong with making it work correctly andd efficiently in the case of global static variables and also nothing wrong with ifdefing that support so its not on by default. Later if there is a either port specific or real generic need the support can be turned on.

I guess I'm a bit surprised your willing to leave a basic class like AtomicString broken because of current design decisions event if there often (not always) correct. At the very least add a comment to the header.

Its tough to wager on a email list but I promise to buy and extra ipod if this is not fixed within the next two years. I don't see me loosing that bet :)

Mike

...

-- Darin