It's an annotation that is used a lot, and should be used even more, so a
shorter name is better.
MozReview-Commit-ID: 1VS4Dney4WX
--HG--
extra : rebase_source : b26919c1b0fcb32e5339adeef5be5becae6032cf
We have inconclusive evidence that compartmentStats is sometimes nullptr during
memory reporting, which would be bad. This patch makes us abort in that case.
It also changes some pointers to references to make the expected non-nullness
clearer.
--HG--
extra : rebase_source : c49f727450ce065d0e84d7728057c93d35353e91
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
|oOps| is short for "objectOps", which will contrast with the |cOps| "classOps"
field that the next patch will introduce.
--HG--
extra : rebase_source : 920662674e1f672d923cb9060de23c85dfc903bf
This will help identify the cause of some Firefox start-up crashes when JS
initialization fails.
--HG--
extra : rebase_source : 3ed3c5e60f487e0ca11dc13bab93aa820ca8273f
js::ClassExtension is often all null. When it's not all null, it's often
duplicated among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 17 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : eb78ade09ce268e886d091f6cbc38d7e5e912527
Exceptions:
- AutoSetNewObjectMetadata and its related type are still exclusively about objects.
- JSCompartment::objectMetadataTable is still only about objects.
- the ObjectMetadataMap type still only has objects as keys.
Non-exceptions:
The builder type, and the JSCompartment member:
ObjectMetadataCallback -> AllocationMetadataBuilder
objectMetadataCallback -> allocationMetadataBuilder
jsfriendapi.h interface:
SetObjectMetadataCallback -> SetAllocationMetadataBuilder
GetObjectMetadata -> GetAllocationMetadata
JSCompartment methods:
hasObjectMetadataCallback -> hasAllocationMetadataBuilder
getObjectMetadataCallback -> getAllocationMetadataBuilder
setObjectMetadataCallback -> setAllocationMetadataBuilder
forgetObjectMetadataCallback -> forgetAllocationMetadataBuilder
addressOfMetadataCallback -> addressOfMetadataBuilder
Shell and testing functions:
SavedStacksMetadataCallback -> SavedStacksMetadataBuilder
ShellObjectMetadataCallback -> ShellAllocationMetadataBuilder
EnableShellObjectMetadataCallback -> EnableShellAllocationMetadataBuilder
enableShellObjectMetadataCallback -> enableShellAllocationMetadataBuilder
GetObjectMetadata -> GetAllocationMetadata
getObjectMetadata -> getAllocationMetadata
Delayed metadata collection:
shouldDelayMetadataCallback -> shouldDelayMetadataBuilder
JSCLASS_DELAY_METADATA_CALLBACK -> JSCLASS_DELAY_METADATA_BUILDER
suppressObjectMetadataCallback -> suppressAllocationMetadataBuilder
--HG--
extra : rebase_source : 54af5a56edd9b39466fa418f7a72fc586d0482d3
js::ClassSpec is often all null. When it's not all null, it's often duplicated
among classes. By pulling it out into its own struct, and using a (possibly
null) pointer in js::Class, we can save 138 KiB per process on 64-bit, and half
that on 32-bit.
--HG--
extra : rebase_source : 852ac6770ace46958d018107e78c5c44ebd6528a
This commit adds `SharedImmutableStringsCache` which allows for de-duplication
and sharing of immutable strings between threads and JSRuntimes.
Each JSRuntime gets a SharedImmutableStringsCache member, but the accessor
always returns the parent runtime's cache. The caches in child JSRuntime's are
not wasting space, however, as initialization and allocation of the table
happens lazily within SharedImmutableStringsCache.
Furthermore, this commit removes `js::ScriptSource::Parent` and the
`CompressedSourceSet`. They are unnecessary because source text is always shared
via the parent runtime's `SharedImmutableStringsCache` now.
js::ObjectOps is often all null. When it's not all null, it's often duplicated
many times among classes. By pulling it out into its own struct, and using a
(possibly null) pointer in js::Class, we can save 208 KiB per process on
64-bit, and half that on 32-bit.
--HG--
extra : rebase_source : 5be8fe45f652392571b8a6d7b63777cbafba6ae4
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
There can be multiple compartments within the same zone, only one of which is a
debuggee. In this scenario, CCWs from other compartments into the debuggee
compartment should be traced and treated as roots. Therefore, dealing with CCWs
at the JS::Zone level is incorrect, and this patch changes the granularity level
to JSCompartments. If you look at the callers and uses of the function, it makes
much more sense now.
Additionally, it renames `JS_TraceIncomingCCWs` to `JS::TraceIncomingCCWs`.
--HG--
rename : devtools/shared/heapsnapshot/tests/gtest/DoesCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesCrossCompartmentBoundaries.cpp
rename : devtools/shared/heapsnapshot/tests/gtest/DoesntCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesntCrossCompartmentBoundaries.cpp
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.