This adds tracking of malloc memory to WasmInstanceObject, WasmGlobalObject, WasmMemoryObject and ResolveResponseClosure (the straightforward cases).
Differential Revision: https://phabricator.services.mozilla.com/D35485
Because the return address cannot be used to uniquely identify script/pc, this
is unfortunately quite different from what we do for Baseline/Ion code.
The strategy is as follows:
* When the profiler is enabled, ensure each JitScript has a pointer to the
profile string (released when the script is finalized).
* The BaselineInterpreter code is registered with the JitcodeMap.
* The profiler code treats interpreter frames like C++ Interpreter frames,
instead of doing the return address based mapping.
Differential Revision: https://phabricator.services.mozilla.com/D31052
--HG--
extra : moz-landing-system : lando
Once the other data is moved out of PrivateScriptData, this GC-thing array will be stored
at a fixed offset. At that point we can simplify PrivateScriptData and get fast indexing
into this array, important for the Baseline Interpreter.
Differential Revision: https://phabricator.services.mozilla.com/D34902
--HG--
extra : moz-landing-system : lando
Check VM and Realm options that may disable syntax parsing up front in
the CompileOptions constructor. This is needed to make the frontend
closer to a pure-function.
Differential Revision: https://phabricator.services.mozilla.com/D35214
--HG--
extra : moz-landing-system : lando
Check realm flags at when creating CompileOptions rather than during
compilation. This is helpful for pre-compiling self-hosting code.
Differential Revision: https://phabricator.services.mozilla.com/D34976
--HG--
extra : moz-landing-system : lando
All uses of OwningCompileOptions now are initialized from copy() so
remove the now-unused setters.
Differential Revision: https://phabricator.services.mozilla.com/D35080
--HG--
extra : moz-landing-system : lando
Check realm flags at when creating CompileOptions rather than during
compilation. This is helpful for pre-compiling self-hosting code.
Differential Revision: https://phabricator.services.mozilla.com/D34976
--HG--
extra : moz-landing-system : lando
Use memory tracking APIs to track malloc memory associated with the different ctypes objects.
I ended up creating new public APIs because ctypes currently mostly uses our public APIs, but I actaully don't know why. I don't think it can be built standalone. Maybe this should use the internal APIs instead.
Differential Revision: https://phabricator.services.mozilla.com/D34375
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
Previously I rolled the malloc byte count into a total byte count for each zone but this may adversely affect GC scheduling (e.g. by triggering more non-incremental GCs because allocation volumes appear higher with this change). So that we can land this machinery without disturbing benchmarks too much, this patch splits out the new malloc memory accounting into a separate counter and uses the maxMallocBytes setting as the threshold (default value is 128MB vs 30MB for the GC heap threshold) and a growth factor of 2. This should make the behaviour closer to the original behaviour for now. We can go back and adjust the parameters later to obtain the desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D34181
Added thread type as ThreadType enum. Default is ThreadType::THREAD_TYPE_NONE. RunnableTasks must specify their own thread type.
Differential Revision: https://phabricator.services.mozilla.com/D33818
--HG--
extra : moz-landing-system : lando
There are a couple of places where this method is just used to check the thresholds so I made the size parameter default to zero. Perhaps we should make this a separate trigger.
This also adds a separate GC reason for incremental slices trigger from this method so we can distinguish incremental and non-incremental triggers.
Differential Revision: https://phabricator.services.mozilla.com/D33000
This code is debug-only, but it seems a shame to waste have this key structure take up two words when it will fix into one. This also moves the MemoryUse enum definition to gc/GCEnum.h.
Differential Revision: https://phabricator.services.mozilla.com/D32170
