Following up with the changes made in http://dev.w3.org/html5/webvtt/#dfn-dom-vttcue-vertical, this patch comes to create a new enum to validate and control the possible values for TextTrackCue::Vertical. Throwing behavior was removed for spec conformance.
In the current setup, we'll end up GCing once when destroying the SafeJSContext,
and then once again immediately after in the explicit GC we do before destroying
the XPCJSRuntime. It would be nice to avoid the first GC entirely, but we
currently need both to avoid leaking.
All in all, these patches cause us to GC three times during shutdown, rather
than twice as we did before, because the second GC was rolled together with
the runtime destruction GC when we destroyed the last JSContext. There are a
number of ways to eliminate these, at least in opt builds, but mccr8 thinks
it probably doesn't matter, since there shouldn't be much left in the heap after
the second GC.
We can probably get away with eliminating rambo GC entirely at some point. But
this might become irrelevant for the browser if we end up doing bug 662444.
It would also be interesting to see what, if anything, the rambo GC actually
collects. We might even be able to get away with asserting that all the zones
are gone and removing the GC entirely.
We also take the opportunity to kill mOwnSafeJSContext, which no longer holds
any meaning.
This patch is a joint effort between billm and myself. I'm marking myself as
the author because I worked on it more recently, which means that Bill should
probably review it again in addition to jonco, and self-review is frowned upon.
There were a few places where we relied on !rt->hasContexts() to mean
"this is the last GC". That was never really valid, and it especially isn't
valid with the previous patch. This patch replaces the check everywhere it's
used in the GC.
This interacts badly with our attempts to shut things down nicely, and happens
to be entirely unused. the primary impact of it ends up being that the cx
destruction triggers a GC, which we depend on. But we can do that manually.
This patch fixes two small issues.
(1) It tightens an assertion in finalizeNow. Stuff finalized in finalizeNow
should never be finalized off the main thread, so we shouldn't have to
worry about BFS_JUST_FINISHED.
(2) If the only compartment that's left to GC is the atoms compartment, then
we're not collecting it. I just moved the |any| check down below the
code that decides whether to schedule the atoms compartment for GC.
- moz.build updates.
- Use nsISupports thread-safe decleration macros.
- Also with PicoVoice, changed to thread-safe add/remove ref macro. We are now creating them off main thread.
- Do initialization off main thread, but go back to main thread to register the voices.
