All the SizeOf{In,Ex}cludingThis() functions take a MallocSizeOf function
which measures memory blocks. This patch introduces a new type, SizeOfState,
which includes a MallocSizeOf function *and* a table of already-measured
pointers, called SeenPtrs. This gives us a general mechanism to measure
graph-like data structures, by recording which nodes have already been
measured. (This approach is used in a number of existing reporters, but not in
a uniform fashion.)
The patch also converts the window memory reporting to use SizeOfState in a lot
of places, all the way through to the measurement of Elements. This is a
precursor for bug 1383977 which will measure Stylo elements, which involve
Arcs.
The patch also converts the existing mAlreadyMeasuredOrphanTrees table in the
OrphanReporter to use the new mechanism.
--HG--
extra : rebase_source : 2c23285f8b6c3b667560a9d14014efc4633aed51
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
This is basically a cosmetic change; references are the normal way to do string
outparams.
--HG--
extra : rebase_source : ffc5945f269bdcd3d4116755b56713e87a44b6cd
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
It's just a complex wrapper for free(), or equivalent function. (In practice,
all the uses end up in free().)
--HG--
extra : rebase_source : 247ea8458aa57319bd1c8366115a9b4f39ed5a33
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
As well as the straightforward things, this lets us remove ReadSysFile and
WriteSysFile, which in turn lets us remove TestFileUtils.cpp.
--HG--
extra : rebase_source : fc90c05352e654ffc41009d8504a9c54f394fc3f
I actually couldn't figure out a way to trigger this assertion with the
current string code without doing invalid casts, but there are things we
may want to add to the string code in the future that might risk hitting
this (e.g., move constructors, promoting various rebind methods to
nsA[C]String), so I think it's worth asserting.
MozReview-Commit-ID: 4R0dYuTfrFW
--HG--
extra : transplant_source : %B6%87I%0E%7F%21%CC2%19%CD%A7%E6TRA%9D%AEO%90%D7
This is needed for patch 4.
MozReview-Commit-ID: 4BFlTtQdtoN
--HG--
extra : transplant_source : %7C%F7%FDN%E5%7Df%0C%7D%10%EF%C0%25%B9%D6%18%1E%93%BE%A0
This is needed for patch 4.
MozReview-Commit-ID: 5ikQFIL9O0i
--HG--
extra : transplant_source : %88%80%E3%04%11%7E%7F%A4%7E%15%1B%1A%84%E2%13%3E%F6%E8%2A%1C
The simplistic shift-based hashing function creates a lot of collisions
for pointers pointing to arrays as it doesn't do a great job at distributing
the data randomly based on the input bytes.
Running with XPCOM_MEM_LOG_CLASSES=nsStringBuffer triggers an
assertion in refcount logging for nsFakeStringBuffers. These are given
an initial refcount of 1, without calling NS_LOG_ADDREF. Then,
AddRef() is called on these objects in StaticAtom::StaticAtom(), and
we tell the refcount logging system about the fake buffer, and that it
has a refcount of 0, triggering the assertion.
The first part of the fix is to call NS_LOG_ADDREF for this initial
refcount, in StaticAtom().
This first fix causes refcount logging to start reporting that the
fake string buffers leak, when XPCOM_MEM_LOG_CLASSES is not set. This
is because refcount logging is now getting told about these objects
being AddRefed at 1, which it takes to mean that an object is created.
To work around this issue, I add an array gFakeBuffers that contains
every fake string buffer we create, and tell the refcount logging
system that these objects are all being destroyed, when the atom table
is being shut down. This could result in some bogosity if the fake
buffers are "leaked" but hopefully this is still an improvement over
the current state.
MozReview-Commit-ID: 5AxoBYAlYRU
--HG--
extra : rebase_source : ba0763cb494894918141774025db525cea9f9c75
Running with XPCOM_MEM_LOG_CLASSES=nsStringBuffer triggers an
assertion in refcount logging for nsFakeStringBuffers. These are given
an initial refcount of 1, without calling NS_LOG_ADDREF. Then,
AddRef() is called on these objects in StaticAtom::StaticAtom(), and
we tell the refcount logging system about the fake buffer, and that it
has a refcount of 0, triggering the assertion.
The first part of the fix is to call NS_LOG_ADDREF for this initial
refcount, in StaticAtom().
This first fix causes refcount logging to start reporting that the
fake string buffers leak, when XPCOM_MEM_LOG_CLASSES is not set. This
is because refcount logging is now getting told about these objects
being AddRefed at 1, which it takes to mean that an object is created.
To work around this issue, I add an array gFakeBuffers that contains
every fake string buffer we create, and tell the refcount logging
system that these objects are all being destroyed, when the atom table
is being shut down. This could result in some bogosity if the fake
buffers are "leaked" but hopefully this is still an improvement over
the current state.
MozReview-Commit-ID: 5AxoBYAlYRU
--HG--
extra : rebase_source : 967520e825d26c369a11acc478d223d190137a43
For some reason, I continuously ran into windows x64 specific failures when
trying to read this heap allocated data while the main thread was paused. I
don't know specifically how this happened, but I am able to avoid it by instead
directly allocating the buffer in a `mozilla::Array` in static storage, and
copying that data instead.
MozReview-Commit-ID: 473d6IpHlc4
