I kept all the existing PL_DHashTableAdd() calls fallible, in order to be
conservative, except for the ones in nsAtomTable.cpp which already were
followed immediately by an abort on failure.
--HG--
extra : rebase_source : 526d96ab65e4d7d71197b90d086d19fbdd79b7b5
I kept all the existing PL_DHashTableAdd() calls fallible, in order to be
conservative, except for the ones in nsAtomTable.cpp which already were
followed immediately by an abort on failure.
--HG--
extra : rebase_source : eeba14d732077ef2e412f4caca852de6b6b85f55
It feels safer to use a function with a new name, rather than just changing the
behaviour of the existing function.
For most of these cases the PL_DHashTableLookup() result was checked with
PL_DHASH_ENTRY_IS_{FREE,BUSY} so the conversion was easy. A few of them
preceded that check with a useless null check, but the intent of these was
still easy to determine.
I'll do the trickier ones in subsequent patches.
--HG--
extra : rebase_source : ab37a7a30be563861ded8631771181aacf054fd4
- The way NS_StackWalk() sets up |targetThread| and |data.walkCallingThread| is
hard to read.
- The name |shouldBeThreadSafe| is unclear -- for a long time I thought it
meant "we are thread-safe, so we can print" and I thought it was named
incorrectly. But now I see it actually means the opposite, i.e. "we need to
be thread-safe, so we can't print". So |needToBeThreadSafe| would be
clearer...
- ...but |shouldBeThreadSafe| shouldn't be used anyway, because
|data.walkCallingThread| is better -- it correctly handles the case where
|aThread| is the current thread -- and it's what WalkStackMain64() uses.
This patch fixes these problems.
--HG--
extra : rebase_source : f1310f72db1e10c25e77af54a1d6df4114e59314
Currently the setting of PLDHashTable::ops is very haphazard.
- PLDHashTable has no constructor, so it's not auto-nulled, so lots of places
null it themselves.
- In the fallible PLDHashTable::Init() function, if the entry storage
allocation fails we'll be left with a table that has |ops| set -- indicating
it's been initialized -- but has null entry storage. I'm not certain this can
cause problems but it feels unsafe, and some (but not all) callers of Init()
null it on failure.
- PLDHashTable does not null |ops| in Finish(), so some (but not all) callers
do this themselves.
This patch makes things simpler.
- It adds a constructor that zeroes |ops|.
- It modifies Init() so that it only sets |ops| once success is ensured.
- It zeroes |ops| in Finish().
- Finally, it removes all the now-unnecessary |ops| nulling done by the users
of PLDHashTable.
--HG--
extra : rebase_source : bb34979c218d152562a2f9c7e5215256c111cc5b
The new "num" property lets identical blocks be aggregated in the output. This
patch only uses the "num" property for dead blocks, because that's where the
greatest potential benefit lies, but it could be used for live blocks as well.
On one test case (a complex PDF file) running with --mode=cumulative
--sample-below=1 this patch had the following effects.
- Change in running speed was negligible.
- Compressed output file size dropped from 8.8 to 5.0 MB.
- Compressed output file size dropped from 297 to 50 MB.
- dmd.py runtime (without stack fixing) dropped from 30 to 8 seconds.
--HG--
extra : rebase_source : 46a32058cd5c31cd823fe3f1accb5e68bcd320f3
The DEFINES and XPCOM_API changes are needed to get rid of "inconsistent dll
linkage" warnings on Windows builds.
--HG--
extra : rebase_source : 00756f51ebee85c70f65d51dbac17b4835262697
