6 ms·

Has anyone read the part about the new jsval types? http://blog.mozilla.com/rob-sayre/2010/08/02/mozillas-new-javascript-value-representation/ http://blog.mozil

Has anyone read the part about the new jsval types? http://blog.mozilla.com/rob-sayre/2010/08/02/mozillas-new-javascript-value-representation/ http://blog.mozilla.com/rob-sayre/2010/08/02/mozillas-new-ja... 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?

NinetyNine 16y ago
I'm not sure I'm understanding you right; a hex character is four bits. To tease a hex character out of a 32 bit int, you'd apply a max of 0000000F, where F is the last four bits.
- euroclydon 16y ago
  In the example, if the last four bits are 1100, it's a string. The first seven four-bit quadruplets, plus a bitmask'd version of the last quadruplet (1100) comprised eight sets for four bits. My questions is: how can four bits, if they don't already encode the hex character I'm looking for, be bitmask'd into displaying it, and still be capable of encoding any of the 16 possible hex characters?
  - Benjo 16y ago
    Where do you see 4 bits? I only see him mention 3 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.
  - wvenable 16y ago
    If the last 3 bits are 100 then the value is a pointer to a string. You mask off those 3 bits and you get the address of the string -- you just have to ensure your strings are aligned to 8 byte boundaries.
DEinspanjer 16y ago
I couldn't figure that out either, so I asked a friend who actually worked on this code and I came away feeling just a tad dirty but smarter. :) 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.

NinetyNine 16y ago

I'm not sure I'm understanding you right; a hex character is four bits. To tease a hex character out of a 32 bit int, you'd apply a max of 0000000F, where F is the last four bits.

euroclydon 16y ago
In the example, if the last four bits are 1100, it's a string. The first seven four-bit quadruplets, plus a bitmask'd version of the last quadruplet (1100) comprised eight sets for four bits. My questions is: how can four bits, if they don't already encode the hex character I'm looking for, be bitmask'd into displaying it, and still be capable of encoding any of the 16 possible hex characters?
- Benjo 16y ago
  Where do you see 4 bits? I only see him mention 3 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.
- wvenable 16y ago
  If the last 3 bits are 100 then the value is a pointer to a string. You mask off those 3 bits and you get the address of the string -- you just have to ensure your strings are aligned to 8 byte boundaries.

DEinspanjer 16y ago

I couldn't figure that out either, so I asked a friend who actually worked on this code and I came away feeling just a tad dirty but smarter. :) 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.