You know, as soon as you're willing pass 64-bit values around, packing different values into a long long isn't really packing anymore. There are so many bits that you can easily "waste" a few of them for tags. The downside is that you most often really just need only a handful of bits and it looks like Jaegermonkey lavishly uses 32 bits for tagging of 32-bit pointers.
Of course, thinking optimistically, the new approach is better if you can at least carry some satellite information in the 32 tag bits, like object origination/permission/context data, or some length/offsets for (sub)strings. Also, locality is probably better, heap allocation is eliminated, and for 64-bit registers and moves this is a natural fit.
But I would have liked to see those 61-bit integers for the same amount of money.
Of course this is not new. I would have to assume that every value representation under the sun has already been invented and probably during the 60s.
61-bit integers would either require long long integer arithmetic on x86 or require more dynamic branching for arithmetic ops either of which would slow down very hot paths.
You know, as soon as you're willing pass 64-bit values around, packing different values into a long long isn't really packing anymore. There are so many bits that you can easily "waste" a few of them for tags. The downside is that you most often really just need only a handful of bits and it looks like Jaegermonkey lavishly uses 32 bits for tagging of 32-bit pointers.
Of course, thinking optimistically, the new approach is better if you can at least carry some satellite information in the 32 tag bits, like object origination/permission/context data, or some length/offsets for (sub)strings. Also, locality is probably better, heap allocation is eliminated, and for 64-bit registers and moves this is a natural fit.
But I would have liked to see those 61-bit integers for the same amount of money.