We already have an accessor to make sure this is can only be set but not
cleared so hide the underlying storage.
Differential Revision: https://phabricator.services.mozilla.com/D42559
--HG--
extra : moz-landing-system : lando
Also closes bug 1576216: update ZoneStats and RealmStats memory
accounting for this change.
Differential Revision: https://phabricator.services.mozilla.com/D42977
--HG--
extra : moz-landing-system : lando
This renames:
HeapSize::gcBytes -> bytes (it's not just for GC heaps any more)
ZoneThreshold -> HeapThreshold (to go with HeapSize)
HeapThreshold::triggerBytes -> bytes (what else could it be?)
I renamed the ZoneAllocator members to make them more uniform/consitent so we now have gcHeapSize/gcHeapThreshold, mallocHeapSize/mallocHeapThreshold etc.
I also renamed the heap threshold classes.
Differential Revision: https://phabricator.services.mozilla.com/D42868
--HG--
extra : moz-landing-system : lando
The final huge patch. This is a search-and-replace removal of js::Class followed by clang-format and removal of the alias from TypeDecls.h.
Depends on D41986
Differential Revision: https://phabricator.services.mozilla.com/D41987
--HG--
extra : moz-landing-system : lando
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
Another big patch. This a search-and-replace followed by mach clang-format, and removal of the js::ClassOps alias from Class.h.
Differential Revision: https://phabricator.services.mozilla.com/D41761
--HG--
extra : moz-landing-system : lando
This removes the original js::ClassOps but leaves it aliased to JSClassOps so everything compiles for now.
Differential Revision: https://phabricator.services.mozilla.com/D41759
--HG--
extra : moz-landing-system : lando
Patch to report JS GC things that are live at shutdown as leaks by calling MOZ_LOG_CTOR for them. The JS engine now clears any remaining roots to prevent dangling pointers to freed memory after shutdown. I made XPCJSRuntime::Shutdown keep the weak pointer update callbacks as sometimes these tables have entries remaining at shutdown (if there are leaks) and we need the callbacks to update them.
This is looking more green on try now.
Differential Revision: https://phabricator.services.mozilla.com/D40449
--HG--
extra : moz-landing-system : lando
There are about the same number of occurrences of "ENABLE_INTL_API" and "EXPOSE_INTL_API"
in the tree, so preferring one over the other doesn't lead to fewer changes. Therefore
I went with "ENABLE_INTL_API", because "ENABLE_" (resp. "MOZ_ENABLE") is already used as
the prefix for other preprocessor ifdef's.
Differential Revision: https://phabricator.services.mozilla.com/D41188
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Introduces SweepingTracer and TraceWeakEdge to trace weak references in
AtomsTable::sweep and AtomsTable::sweepIncrementally while sweeping.
Also rename those two functions to traceWeak and traceWeakIncrementally.
Differential Revision: https://phabricator.services.mozilla.com/D40939
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Rather than make re-enabling the nursery work correctly (because there's
various ways to disable it and we'd need to make sure we're enabling it for
the right reason). It's simplier just to not disable it for a
gcMaxNurseryBytes of 0, and instead return an error.
Differential Revision: https://phabricator.services.mozilla.com/D39988
--HG--
extra : moz-landing-system : lando
This replaces the original JIT code memory counter with one that tracks the allocated JIT code precisely. This now uses a fixed threshold which was the original intention.
This also removes the INCREMENTAL_MALLOC_TRIGGER GC reason and all GCs triggered by malloc allocations use TOO_MUCH_MALLOC, so whether a GC is incremental is separated from the trigger reason.
Differential Revision: https://phabricator.services.mozilla.com/D39734
--HG--
extra : moz-landing-system : lando
This adds two new parameters. The growth fator is set to 1.5 and the base to 42MB. Trail and error showed that this latter value ended up triggering GCs roughtly in line with the old malloc counter. These values make the initial malloc threshold ~64MB.
Differential Revision: https://phabricator.services.mozilla.com/D39730
--HG--
extra : moz-landing-system : lando
Now that IonBuilder only depends on JitScript we no longer need to have a BaselineScript.
Differential Revision: https://phabricator.services.mozilla.com/D39168
--HG--
extra : moz-landing-system : lando
Avoid manual allocations and use default constructors when possible to
simplify code.
Differential Revision: https://phabricator.services.mozilla.com/D37946
--HG--
extra : moz-landing-system : lando
JS_TransplantObject is a very powerful API that results in the JITs
having to worry about the type of objects changing in surprising ways.
In practice though, there are very limited uses of this API so we can
add an API to determine which objects have to worry about transplanting.
This can then by asserted in JITs to document places that optimize
performance by expecting not to deal with transplants.
Differential Revision: https://phabricator.services.mozilla.com/D27975
--HG--
extra : moz-landing-system : lando
Also use default constructors when possible to remove duplications.
Depends on D37944
Differential Revision: https://phabricator.services.mozilla.com/D37945
--HG--
extra : moz-landing-system : lando
Replace HashMap<T>* with Maybe<HashMap<T>> in memory reporting to have
simpler code and better ergonimics.
Differential Revision: https://phabricator.services.mozilla.com/D37944
--HG--
extra : moz-landing-system : lando
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
Also reorder functions in OffThreadScriptCompilation to group by
data source type.
Differential Revision: https://phabricator.services.mozilla.com/D37575
--HG--
extra : moz-landing-system : lando
Because ShouldIncludeEdge considers the |origin| node as well, it was possible for
the old code to 'miss' nodes and never write them to the core dump even though we
also wrote some edges with the node as referent.
Differential Revision: https://phabricator.services.mozilla.com/D37701
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
Update the memory pressure observers for main thread and workers to call the new JS API to set/clear the low memory state.
Differential Revision: https://phabricator.services.mozilla.com/D35682
Patch to use std::move when passing AllocPolicy instances to constructors. This also fixes HashTable move constuction/assignment that previously PodAssigned the whole object including the AllocPolicy base.
Differential Revision: https://phabricator.services.mozilla.com/D36175
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
Also JSScript::makeTypes => JSScript::createJitScript for consistency with code
elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D31755
--HG--
extra : moz-landing-system : lando
The new trace logger spew routines do not have a corresponding empty inline version for when --disable-trace-logging is used.
Differential Revision: https://phabricator.services.mozilla.com/D32156
--HG--
extra : moz-landing-system : lando
Add Jitspewing control for tracelogger data. This can be enabled from the profiler or from the JS shell. Usage is as follows:
From browser (ION_SPEW_FILENAME is recommended here so stdout doesn't get clobbered by each process):
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger ION_SPEW_FILENAME=tracelogger ./mach run
2. Enable JSTracer feature in profiler addon
3. Start profiling and ctrl+shift+2 to view profile, and the data will be automatically spewed during profile collection.
From shell:
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger dist/bin/js test.js
2. Data is automatically spewed to stdout when the shell exits, or use ION_SPEW_FILENAME.
There is an optional environment variable JS_TRACELOGGER_SPEW that can be used to emit specific events, for example JS_TRACELOGGER_SPEW="Interpreter,Baseline,GC" will emit only those specific events along with the script and self time of each script.
The structured spewer is also supported with SPEW=tracelogger, and this will emit the tracelogger data for every recorded event.
Differential Revision: https://phabricator.services.mozilla.com/D30033
--HG--
extra : moz-landing-system : lando
Add a special path for the external read barrier API where we inline most of the checks and then always perform the barrier if we call into the engine. This also skips dispatching on trace kind since we know the barrier tracer is always a GCMarker.
This is kind of hacky and I'm not sure how much it gains us (it's difficult to tell in profiles where GC may occur at different times). What do you think?
Differential Revision: https://phabricator.services.mozilla.com/D31803
--HG--
extra : moz-landing-system : lando
This replaces the use of heap-alloced Rooted with PersistentRooted which is safe wrt destruction order.
I had to add PersistentRooted and StackGCVector to OPAQUE_TYPES to make this work... I'm not really sure what this does.
Differential Revision: https://phabricator.services.mozilla.com/D30668
--HG--
extra : moz-landing-system : lando
