Bug 202005
| Summary: | Consider a 14-bit JSValue tag scheme with always materializing one of the 3 needed masks. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mark Lam <mark.lam> |
| Component: | JavaScriptCore | Assignee: | Mark Lam <mark.lam> |
| Status: | ASSIGNED | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Mark Lam
If we're willing to use 3 tag registers or always materialize one of them, we can also adopt a 14-bit tag as follows:
Pointer { 0000:PPPP:PPPP:PPPP
/ 0002:****:****:****
Double { ...
\ FFFC:****:****:****
Integer { FFFF:0000:IIII:IIII
where we need to use 3 different masks to differentiate between cells, ints, and doubles:
NumberMask is 0xfffc: any bits set in the top 14 bits is a number.
IntMask is 0xffff: value is int if value & IntMask == IntMask.
NotCellMask is NumberMask | OtherTag.
Since the highest double is "negative" pureNaN i.e. starts with 0xfff8, adding a DoubleEncodeOffset of 1<<50 (starts with 0x0004) produces 0xfffc which is still less than 0xffff (the IntMask).
The downside of this scheme is that materializing a mask or burning a 3rd register on a mask, will have performance impact. We can measure if this impact is significant.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |