Firefox 4 Beta 3 Released
mozilla.com
mozilla.com
According to the author, the old way was to store all JS vars in 32bit C variables, so a small int was able to be stored inline, but floats, objects and strings were stores as pointers.
The author says that the last four bits stored the type info for the variable. But, since memory addresses are 8 hex characters long, a bitmask was used to convert the last four bits into another hex character, thus establishing the full pointer address.
How does this work? I mean, you only have the four bits, if the info is not right there in front of my face in those four bits, how can a mask tease out the hex character?
The last three bits of the real address are always 000.
If you ask C's malloc for enough space to store a JS string, object, or float, the address that it gives you will be aligned on a 32-bit boundary, so the last three bits of the address will be 0. SpiderMonkey has it's own allocator, mostly because they do GC, but this allocator also guarantees that any address allocated for one of these types is aligned.
Because of this, the last three bits can always be used to store the type tag and then masked away to restore the proper 000 bits.
The old jsval representation fit in a 32 bit value, using the 3 lowest bits as a way to tag the value as a particular type. These were called type tags.
In the examples given, the lowest three bits are masked to 0s when determining the address. That's a loss of precision, meaning there's no way to represent a pointer to an address that's not modulo 8 == 0. Another way of saying this is that objects must be aligned to 8 byte boundaries.
Isn't this a waste of space? Probably not. My guess is very few objects are less than 8 bytes in length, so that space is not really wasted. Even if objects ARE shorter, this is a dynamically typed language, we probably want to keep spare memory anyway, to reduce the chance that adding values to an object will require costly memory allocation.
Also: The "tabs on top" on OS X could use some touching-up - right now the tab bar is just swapped with the toolbar, and still below the window's title area. Something more like Chrome (or that Safari beta, for that matter) would be nice.
Oh well, hopefully it is fixed by the time it is actually released.
I suppose this makes me that guy that shows up in every Firefox thread complaining that it's a shitty Mac app.
Search bar is supported in about:config, but the others aren't.
So far, the beta looks good to me. But I'm dying without the rest of my extensions.
Also, copy and paste was broken in B2, anyone know if this is fixed in B3?