This also effectively changes how DMD is enabled from requiring both
replace-malloc initialization and the DMD environment variable to
requiring only the former. The DMD environment variable can still be
used to specify options, but not to disable entirely.
This however doesn't touch all the parts that do enable DMD by setting
the DMD environment variable to 1, so the code to handle this value
is kept.
Doing this means that instantiations of nsRefPtr<T> won't require
nsCOMPtr_helper::operator() to be defined. Only actual uses of the
overloads will require the definition.
Forward declaring functions with default arguments is difficult. If you try to say:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags);
and then later have:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags = 0);
{
...
}
the compiler complains that default arguments cannot be added to a
function template that has already been declared. If you attempt to
mollify the compiler by declaring instead:
template<typename T>
inline void
CycleCollectionNoteChild(nsCycleCollectionTraversalCallback& aCallback,
T* aChild, const char* aName, uint32_t aFlags = 0);
the compiler then complains about redefining the default argument (!)
when an actual definition is found.
To circumvent this, manually implement "default" arguments by providing
a three-argument form of CycleCollectionNoteChild, which simply forwards
to the four-argument version.
The interesting feature JSONWriteFunc has, contrary to JSONWriter, is that it
only has virtual methods, which makes it a better candidate to be passed
around between libraries not linked against each other.
This will allow to make dmd and libxul independent from each other.
This patch does the following.
- Moves the logic for computing the ideal capacity for a SegmentedArray out of
SnowWhiteKiller into its own class, SegmentedArrayCapacity.
- Replaces the nsTArray in CollectWhite(), which can be very large and is
complicit in ~1% of OOM crashes, with a SegmentedArray.
--HG--
extra : rebase_source : 732743311a08fcc3dfe43a1b308846b93d30e6ed
This patch generalizes SegmentedArray a little, and then uses it instead of
nsTArray in SnowWhiteKiller. This avoids some large (sometimes 1 MiB or more)
allocations which were usually mostly unused.
This adds "hasSeccompBPF" for seccomp-bpf support; other "has" keys
will be added in the future (e.g., user namespaces).
This also adds "canSandboxContent" and "canSandboxMedia", which are
absent if the corresponding type of sandboxing isn't enabled at build
type (or is disabled with environment variables), and otherwise present
as a boolean indicating whether that type of sandboxing is supported.
Currently this is always the same as hasSeccompBPF, but that could change
in the future.
Some changes have been made to the "mozilla/Sandbox.h" interface to
support this; the idea is that the MOZ_DISABLE_*_SANDBOX environment
variables should be equivalent to disabling MOZ_*_SANDBOX at build time.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This fixes the download panel issue, and brings us revs 727721e5d8ac,
844b142d8111 and 236989b3a807 as a bonus. Remove the unmaintained
OpenBSD/amd64 specific versions.
Root() does not actually root JS things, so if some other class's Unlink() method ends
up calling the GC, whiteNodes will end up containing dead pointers. (This is safe right
now because the Unlink and Unroot methods do not do anything to JS things.) It is less
error prone to simply never store those pointers.
Also, add some asserts to enforce that we never call any of the white-object methods
for JS things.
If an Unlink() method ends up running JS, it can cause a GC, which will make us reenter the CC,
which will not do anything because we're already in a CC. Therefore, FinishAnyCurrentCollection()
won't finish the CC. This is safe because the CC only touches things it actually holds alive via
the Root() method.
On B2G, there are crashes very late in shutdown on content processes. On Windows XP,
there is an intermittent test failure. We work around both of these by calling exit(0)
during XPCOM shutdown prior to the points where these errors occur. This enables us to
land part 4, that stops us from crashing in content processes when the xpcom-shutdown
message is sent, and enables leak checking in content processes on Linux.
We build without UNICODE, so we end up calling the ANSI version
of the function, and then we would attempt to interpret the
resulting narrow char buffer as a wide char buffer.
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.
In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).
On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.
Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.
To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.
In case of multiple "resource" manifest entries for the same keyword, the
last registered one now takes precedence, like any other chrome manifest
entry.
This patch adds another implementation of BaseTimeDuration's ValueCalculator
template parameter that is careful to preserve Forever/-Forever values when
performing arithmetic.
It also defines a typedef for a specialization of BaseTimeDuration that uses
this new ValueCalculator definition.
This patch builds on the templatization from the previous patch to move
arithmetic on the mValue member of BaseTimeDuration to the ValueCalculator
template parameter.
This patch prepares the way for having a separate StickyTimeDuration class
by factoring TimeDuration into a templated base class: BaseTimeDuration.
BaseTimeDuration takes a templated parameter, ValueCalculator, which is a helper
object that defines how various arithmetic operations are performed on its
mValue member (an int64_t count of ticks).
This patch does not actually define or use the ValueCalculator parameter yet but
simply performs the renaming and templatization.
With regards to the templatization, arithmetic operators are defined to take
objects with the same ValueCalculator template parameter (so that we don't, for
example, apply non-safe arithmetic to a StickyTimeDuration).
However, comparison operators are defined to also operate on objects with
a different ValueCalculator template parameter since comparison should be
independent of the type of arithmetic used.
Likewise, the constructor and assignment operator are defined to operate on
objects with a different ValueCalculator template parameter so that objects can
be converted from TimeDuration to StickyTimeDuration and vice-versa.
The constructor is marked as explicit, however, so that we don't silently
convert a StickyTimeDuration to a TimeDuration and unwittingly apply
non-safe arithmetic to a StickyTimeDuration.
TimeDuration is defined as a specialization of BaseTimeDuration that uses
TimeDurationValueCalculator as its ValueCalculator type.
TimeDurationValueCalculator is filled-in in a subsequent patch.
Now that the implementation of a number of TimeDuration methods have been
delegated to a separate TimeDurationPlatformUtils class, it is easier to add
consistent handling to the parameters passed to and from those methods.
This patch adds checks when converting between TimeDurations and doubles so that
Forever (represented by a tick count of INT64_MAX) is paired with
PositiveInfinity, and INT64_MIN is paired with NegativeInfinity.
In order to have different templated versions of TimeDuration we first split out
the platform-specific code so that this code doesn't need to concern itself with
templates (and because putting template code in .cpp files is messy).