The original changeset that is being backed out had comment:
Bug 1023941 - Part 5: Loader hook to redirect the missing import.
The changes made in bug 1023941 were to work around the fact that with VS2013, msvcr120.dll imports kernel32!GetLogicalProcessorInformation, which is not available on Windows XP SP2.
In VS2015, the GetLogicalProcessorInformation requirement has moved into concrt140.dll (concurrency runtime), which we don't use.
So, now that our build infra is building with VS2015, we can remove the hooking and static runtime linking required to get the VS2013 fix to work.
In addition we need to do that to be able us to link the Chromium sandbox code into firefox.exe and get it to build and run with both VS2015 and VS2013.
MozReview-Commit-ID: 1tlXaYJ8dHH
--HG--
extra : rebase_source : 49b216e34fc5c77af96df1f67ee44c46d5368bfe
This commit adds `SharedImmutableStringsCache` which allows for de-duplication
and sharing of immutable strings between threads and JSRuntimes.
Each JSRuntime gets a SharedImmutableStringsCache member, but the accessor
always returns the parent runtime's cache. The caches in child JSRuntime's are
not wasting space, however, as initialization and allocation of the table
happens lazily within SharedImmutableStringsCache.
Furthermore, this commit removes `js::ScriptSource::Parent` and the
`CompressedSourceSet`. They are unnecessary because source text is always shared
via the parent runtime's `SharedImmutableStringsCache` now.
This makes things clearer and removes some unnecessary nsresult checks.
The patch also:
- removes some unnecessary |new| and moz_xmalloc() checks;
- adds MOZ_MUST_USE to some fallible nsVariant methods.
--HG--
extra : rebase_source : fd0bd0c55c22ebf194246ec9997fe971cf282e69
Most of the XPCMap classes contain a |PLDHashTable*|. This can be changed to a
|PLDHashTable|, which avoids some malloc/free calls, removes the needs for
explicit destructors, and removes "can this pointer be null?" questions.
The patch also cleans up the iterators provided by XPCMap classes a little.
MozReview-Commit-ID: K0VdJdZSM7z
--HG--
extra : rebase_source : 9991c6510b86ef39d21009faa37c51a3f37e623d
It appears to cause crashes, and the effects of not calling on memory reporting
accuracy are minor. The code should be able to be re-enabled once
heap-allocated js::Class instances no longer occur.
--HG--
extra : rebase_source : 6dcf36aa21ade45b0397b3df531aaaa8f754af49
XPC_WN_WithCall_ObjectOps and XPC_WN_NoCall_ObjectOps are both equal to
JS_NULL_OBJECT_OPS.
As a result, XPC_WN_ModsAllowed_{With,No}Call_Proto_JSClass are identical, as
are XPC_WN_NoMods_{With,No}Call_Proto_JSClass. (In both cases, modulo the class
name.)
This patch merges those identical-except-for-their-name pairs, resulting in
XPC_WN_ModsAllowed_Proto_JSClass and XPC_WN_NoMods_Proto_JSClass.
--HG--
extra : rebase_source : 64c5990fa5dd09418466ee25a24300bb9cfd3596
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
|oOps| is short for "objectOps", which will contrast with the |cOps| "classOps"
field that the next patch will introduce.
--HG--
extra : rebase_source : 920662674e1f672d923cb9060de23c85dfc903bf
