3 ms·

v8 does not use NaN-boxes; instead they use the low bit to distinguish between a 31-bit small integer ("smi") or a pointer. Doubles are additionally sometimes s

v8 does not use NaN-boxes; instead they use the low bit to distinguish between a 31-bit small integer ("smi") or a pointer. Doubles are additionally sometimes stored inline ("double field unboxing") I'm not sure how this works exactly. Other times they are heap-allocated. I am not sure if there is a specialized double-allocator, I'd like to know. JavaScriptCore uses a tweaked NaN-box [1]: values are stored via a NaN box minus a constant, which avoids requiring a mask when chasing pointers. This makes pointers cheaper but floating point operations more expensive. SpiderMonkey and Hermes both use straight NaN-boxing to my knowledge. https://github.com/WebKit/WebKit/blob/ec6b5337e777f9b460ec6b8b9a82a648fe461764/Source/JavaScriptCore/runtime/JSCJSValue.h#L403 https://github.com/WebKit/WebKit/blob/ec6b5337e777f9b460ec6b...

moonchild 4y ago
> avoids requiring a mask when chasing pointers This, unfortunately, is an artificial limitation; negative nans may correspond to canonical addresses, but most oses won't let you map negative memory, keeping it all to themselves.
- repiret 4y ago
  It’s not even always architecturally possible - ARMv8 doesn’t support user-space mappings with bit 63 set, for example.
  - moonchild 4y ago
    I see. I was talking specifically about x86 here (and the conventions of mainstream OSes hosted on it); obviously, every platform is unique. It looks like on arm, the high bit of an address is used as a special marker to indicate which translation table should be used to look up the rest of the address. I am no arm expert, but looking at the documentation at [0], it does not seem like allowing 'userspace' access to addresses mapped in TTBR1 would be an insurmountable challenge. 0. https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/CP15-c2--Translation-table-support-registers https://developer.arm.com/documentation/ddi0406/b/System-Lev...
- mmoskal 4y ago
  The way it works is that pointers are represented as themselves, assuming top 15 bits being zero. Doubles are shifted by an offset such that nans land at top 15 bits being zero. So assuming pointers are at most 49 bits you're fine.
  - moonchild 4y ago
    My point is that, if the system were more cooperative, you would not need to 'shift by an offset'.

moonchild 4y ago

> avoids requiring a mask when chasing pointers This, unfortunately, is an artificial limitation; negative nans may correspond to canonical addresses, but most oses won't let you map negative memory, keeping it all to themselves.

repiret 4y ago
It’s not even always architecturally possible - ARMv8 doesn’t support user-space mappings with bit 63 set, for example.
- moonchild 4y ago
  I see. I was talking specifically about x86 here (and the conventions of mainstream OSes hosted on it); obviously, every platform is unique. It looks like on arm, the high bit of an address is used as a special marker to indicate which translation table should be used to look up the rest of the address. I am no arm expert, but looking at the documentation at [0], it does not seem like allowing 'userspace' access to addresses mapped in TTBR1 would be an insurmountable challenge. 0. https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/CP15-c2--Translation-table-support-registers https://developer.arm.com/documentation/ddi0406/b/System-Lev...
mmoskal 4y ago
The way it works is that pointers are represented as themselves, assuming top 15 bits being zero. Doubles are shifted by an offset such that nans land at top 15 bits being zero. So assuming pointers are at most 49 bits you're fine.
- moonchild 4y ago
  My point is that, if the system were more cooperative, you would not need to 'shift by an offset'.