PLDHashTable's entry store has two types of unoccupied entries: free
entries and removed entries. The search of a chain of entries
(determined by the hash value) in the entry store to search for an entry
can stop at free entries, but it continues across removed entries,
because removed entries are entries that may have been skipped over when
we were adding the value we're searching for to the hash, but have since
been removed. For live entries, we also maintain this distinction by
using one bit of storage for a collision flag, which notes that if the
hashtable entry is removed, its place in the entry store must become a
removed entry rather than a free entry.
When we add a new entry to the table, Add's semantics require that we
return an existing entry if there is one, and only create a new entry if
no existing entry exists. (Bug 1352198 suggests the possibility of a
faster alternative Add API where the caller guarantees that the key is
not already in the hashtable.) When we search for the existing entry,
we must thus continue the search across removed entries, even though we
record the first removed entry found to return if the search for an
existing entry fails.
The existing code adds the collision flag through the entire table
search during an Add. This patch changes that behavior so that we only
add the collision flag prior to finding the first removed entry. Adding
it after we find the first removed entry is unnecessary, since we are
not making that entry part of a path to a new entry. If it is part of a
path to an existing entry, it will already have the collision flag set.
This patch effectively puts an if (!firstRemoved) around the else branch
of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that
condition outwards since it is now around the contents of both the if
and else branches.
MozReview-Commit-ID: CsXnMYttHVy
--HG--
extra : transplant_source : 0T%B0%FA%C0%85v%8B%16%E7%81%03p%F5K%97%B1%9E%92%27
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : 8%8Ci%CC%EA%0F%CF%C7%3E%F1%93%F5%C9%ED9%84%F9%3Evx
PLDHashTable's entry store has two types of unoccupied entries: free
entries and removed entries. The search of a chain of entries
(determined by the hash value) in the entry store to search for an entry
can stop at free entries, but it continues across removed entries,
because removed entries are entries that may have been skipped over when
we were adding the value we're searching for to the hash, but have since
been removed. For live entries, we also maintain this distinction by
using one bit of storage for a collision flag, which notes that if the
hashtable entry is removed, its place in the entry store must become a
removed entry rather than a free entry.
When we add a new entry to the table, Add's semantics require that we
return an existing entry if there is one, and only create a new entry if
no existing entry exists. (Bug 1352198 suggests the possibility of a
faster alternative Add API where the caller guarantees that the key is
not already in the hashtable.) When we search for the existing entry,
we must thus continue the search across removed entries, even though we
record the first removed entry found to return if the search for an
existing entry fails.
The existing code adds the collision flag through the entire table
search during an Add. This patch changes that behavior so that we only
add the collision flag prior to finding the first removed entry. Adding
it after we find the first removed entry is unnecessary, since we are
not making that entry part of a path to a new entry. If it is part of a
path to an existing entry, it will already have the collision flag set.
This patch effectively puts an if (!firstRemoved) around the else branch
of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that
condition outwards since it is now around the contents of both the if
and else branches.
MozReview-Commit-ID: CsXnMYttHVy
--HG--
extra : transplant_source : W4%B8%BA%D5p%102%1B%8D%83%23%E0s%B3%B0f%0D%05%AE
This is the same optimization made for ThreadSafeAutoRefCnt in bug
1277709. However, nsStringBuffer uses a 32-bit reference count all the
time, so it can't easily use ThreadSafeAutoRefCnt.
MozReview-Commit-ID: LpB3xaYbaEE
--HG--
extra : transplant_source : %89%FA%02%402%B1%83%17%81%09%EEw%B0%85%A0%B2%8DK/%D6
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : %8DM%88%E8%B7%B4%D8a%D6%F5%3F%9B%DC%09X%F3%7C%98%DE%21
We need this because the stored values in the hash table may themselves
be main-thread only objects, and destroying them off the main thread
will cause crashes.
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : ba9f626ca2d2852f966e93401b8f8f7543615310
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
This adds an arena allocator that can be used as a drop-in replacement for
NSPR's PLArena. Example usage for defining an 8-byte aligned allocator that
uses a 4K arena size:
mozilla::ArenaAllocator<4096,8> a;
void* memory = a.Allocate(200);
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 0ac96469629a7a933fcf3bf6720c448db45543eb
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
It's a very general mechanism for replacing the implementation of
printf_stderr().
It's primarily used by the profiler, sparingly, and not in an important way.
Worse, it prevents us from using MOZ_LOG in the profiler, which is something I
want. Because if any code that locks gPSMutex also calls MOZ_LOG, that then
calls printf_stderr(), which calls profiler_log(), which locks gPSMutex, which
deadlocks.
The only other use of set_stderr_callback() is for the ultra-hacky,
for-local-use-only copy_stderr_to_file() function, which was added for B2G
debugging and is no longer necessary.
This patch removes set_stderr_callback() altogether.
--HG--
extra : rebase_source : d31ecb482fe5899f62dc56a38e87d91f9271bab0
This tracks TlsAlloc() and TlsFree() calls on Windows for diagnosing crashes when a proces reaches
its limit (1088) for TLS slots. Tracking of TLS allocation is done by intercepting TlsAlloc() and
TlsFree() in kernel32.dll. After initialization, we start tracking the number of allocated TLS
slots. If the number of observed TLS allocations exceeds a high water mark, we record the stack
when TlsAlloc() is called, and the recorded stacks gets serialized in a JSON string ready for
crash annotation.
MozReview-Commit-ID: 5fHVr0eiMy5
This patch changes the crashreporter client code as well as the crash service
code to compute a SHA256 hash of a crash' minidump file and add it to the
crash ping. The crash service code computes the hash on the fly before handing
over the crash to the crash manager; the crash manager will then add it to the
crash ping. The crashreporter client on the other hand sends the hash via the
ping it generates but it also adds it to the event file so that the crash
manager can pick it up and send it along with its own crash ping. On Fennec
the crashreporter activity takes care of computing the hash.
SHA256 hash computation uses nsICryptoHash in the crash service, the
java.security.MessageDigest class in Fennec, the bundled NSS library in the
crashreporter when running on Windows and Mac and the system-provided NSS
library under Linux. The latter is required because the crashreporter client
uses the system curl library which is linked to NSS and which would thus clash
with the bundled one if used together.
This patch introduces two new methods for the nsICrashService interface:
|getMinidumpForID()| and |getExtraFileForID()|, these reliably retrieve the
.dmp and .extra files associated with a crash and ensure the files exist
before returning. These new methods are used in the CrashService for
processing and will become the only way to reliably retrieve those files
from a crash ID.
MozReview-Commit-ID: 8BKvqj6URcO
--HG--
extra : source : a4d8291c56fcde00238ab3166bbe6af6dd602340
This change moves us away from NSPR primitives for our primary
synchronization primitives. We're still using PRMonitor for
ReentrantMonitor, however.
The benefits of this change:
* Slightly faster, as we don't have to deal with some of NSPR's overhead;
* Smaller datatypes. On POSIX platforms in particular, PRLock is
enormous. PRCondVar also has some unnecessary overhead.
* Less dynamic memory allocation. Out of necessity, Mutex and CondVar
allocated the NSPR data structures they needed, which lead to
unnecessary checks for failure.
While sizeof(Mutex) and sizeof(CondVar) may get bigger, since they're
embedding structures now, the total memory usage should be less.
* Less NSPR usage. This shouldn't need any explanation.
This patch adds a series of fallible methods for the rust ns[C]String
bindings, as well as the `set_length` method, which is the same as the
`SetLength` method in C++. `set_length` is marked as unsafe.
The decision was made to make the fallible methods seperate from the
infallible methods, and to use seperate Rust->C++ bindings for each of
them, rather than only binding the fallible bindings, and unwrapping
them in rust-land. This is to try to match the C++ API as closely as
possible, and to ensure that the behavior matches.
MozReview-Commit-ID: FkSomkFUFGD
This adds release bounds checking to ReplaceElementsAt, InsertElementAt, and
InsertElementsAt to make sure the insertion point is within the current array
bounds.
MozReview-Commit-ID: 1pFr8LuOROI
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
This tracks TlsAlloc() and TlsFree() calls on Windows for diagnosing crashes when a proces reaches
its limit (1088) for TLS slots. Tracking of TLS allocation is done by intercepting TlsAlloc() and
TlsFree() in kernel32.dll. After initialization, we start tracking the number of allocated TLS
slots. If the number of observed TLS allocations exceeds a high water mark, we record the stack
when TlsAlloc() is called, and the recorded stacks gets serialized in a JSON string ready for
crash annotation.
MozReview-Commit-ID: 5fHVr0eiMy5
The code to make a ValidatingDispatcher break cycles when we're done with it
assumes that XPCOM is still up and running. This isn't the case during
shutdown. When XPCOM shuts down, we should avoid do_GetMainThread.
MozReview-Commit-ID: 5Gpko9FbFxl
--HG--
extra : rebase_source : 8c00c83b06e890802ade0d6df2a93f64dc8ea376
This just-so-happened to work because nobody refers to the splitter directly by name.
The added gtest doesn't actually prove that this patch fixes anything, but I figured we could use a wide string for good measure.
MozReview-Commit-ID: 1ADy4X44HO1
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
AbstractThread::GetCurrent() can return null if a thread isn't a
default AbstractThread (MainThread, etc). This doesn't get caught in
MozPromise until we try to check for reliability of dispatching on the
thread. Adding asserts to make things clearer on crashes.
MozReview-Commit-ID: AQJwpdTUiHZ
The profiler can currently handle nested calls to profiler_{init,shutdown}() --
only the first call to profiler_init() and the last call to profiler_shutdown()
do anything. And sure enough, we have the following.
- Outer init/shutdown pairs in XRE_main()/XRE_InitChildProcess() (via
GeckoProfilerInitRAII).
- Inner init/shutdown pairs in NS_InitXPCOM2()/NS_InitMinimalXPCOM() (both shut
down in ShutdownXPCOM()).
This is a bit silly, so the patch removes the inner pairs, and adds a
now-needed pair in XRE_XPCShellMain. This will allow gInitCount -- which tracks
the nesting depth -- to be removed in a future patch.
--HG--
extra : rebase_source : 7e8dc6ce81ce10269d2db6a7bf32852c396dba0e
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : 4d5637bcdbeae605b0b99e9192598d48f371b698
Added ASSERTions to nsWindowsDllInterceptor in case of a failed detour hook, with an exception for the RET opcode that appears in ImmReleaseContext. Added documentation about TestDllInterceptor.
--HG--
extra : rebase_source : a3c6fe0949f5503979a062bdaa5f35526ddee73b
This includes a near-jump CALL instruction in x64, which expands to a far-jump CALL with a 64-bit address as inline data. This requires us to abandon the method where we memcpy the code block into the trampoline and, instead, build the trampoline function as we go.
--HG--
extra : rebase_source : 7f90ce5ba1a82dff731aff1ac17117c684b7b2cf
