Our previous representation of private values assumed that the private pointer was aligned, and did some bit twiddling to try to disguise it as a double. Since bug 1293313, it has been unnecessary to set the top bit for a double, so that bit twiddling is unnecessary. There are actual use cases where private values are unaligned, so we should fix this.
While cleaning this up, I also removed unboxPrivateValue, because its only use could be better written using loadPrivateValue directly.
Differential Revision: https://phabricator.services.mozilla.com/D38127
--HG--
extra : moz-landing-system : lando
IsCanonical was only used in StructuredCloneReader::CheckDouble. Two of CheckDouble's three uses already canonicalized the double before checking it, and the third *should* have already done so.
Differential Revision: https://phabricator.services.mozilla.com/D29870
--HG--
extra : moz-landing-system : lando
Back when we first freed the lizard in 1998, it made sense to have copies of NaN/+Inf/-Inf living on the runtime, because Values didn't store doubles inline. That hasn't been true for a long time. This patch gets rid of those.
Differential Revision: https://phabricator.services.mozilla.com/D29868
--HG--
extra : moz-landing-system : lando
We can't generate a constexpr uint64_t containing the bits for positive/negative infinity, because of a (very sensible) static_assert in SpecificNaNBits. This patch adds support to FloatingPoint.h for infinity. The next patch will use it to make JS::InfinityValue constexpr (to match JS::NaNValue).
Differential Revision: https://phabricator.services.mozilla.com/D29869
--HG--
extra : moz-landing-system : lando
1. CanonicalizedDoubleValue should reuse the logic in CanonicalizeNaN.
2. Places that call DoubleValue(CanonicalizeNaN(d)) should just use CanonicalizedDoubleValue(d).
Differential Revision: https://phabricator.services.mozilla.com/D29867
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
This adds a pre write barrier to Heap<T> so that these can be uses as non-roots in the heap without breaking our snapshot at the beginning invariant if they are written to during an incremental GC. This makes it harder to misuse and allows us to take out manual barriers in at least one place.
Differential Revision: https://phabricator.services.mozilla.com/D25083
I only converted a few low hanging fruits to the new API. Having to check for PrivateGCThing, which often can't even appear is a bit annoying, but I don't think we really need a different type.
I think next I can look into some of the extractNonDoubleType uses.
Differential Revision: https://phabricator.services.mozilla.com/D20474
--HG--
extra : moz-landing-system : lando
I only converted a few low hanging fruits to the new API. Having to check for PrivateGCThing, which often can't even appear is a bit annoying, but I don't think we really need a different type.
I think next I can look into some of the extractNonDoubleType uses.
Differential Revision: https://phabricator.services.mozilla.com/D20474
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
