| Commit message (Collapse) | Author | Age | Lines |
|
|
|
| |
Resolves #185
|
|
|
|
| |
Issue #186
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Thanks to Bruno Keith & Niklas Baumstark from the phoenhex team for
finding this issue and reporting it with a proper analysis.
|
| |
|
|
|
|
|
| |
This also removes code duplication by making CallerSetterImpl call
CallerGetterImpl.
|
| |
|
|
|
|
|
| |
This should be all that's needed for #1017, but verification of
impact is definitely desired.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch fixes two related issues.
1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to
communicate with its callback during each compartment switch.
This vector was designed to allow its contents to be stack-allocated
but they turned out to be accidentally heap-allocated.
2. During each tick, the stopwatch fills a vector `recentGroups_`.
This vector always started with minimal capacity and had to grow
repeatedly as groups were added, causing repeated reallocations.
This patch preallocates `recentGroups_` to have the same capacity as the
previous tick. We expect that this should eventually reach a stable size
that closely matches the actual needs of the process.
|
| |
| |
| |
| | |
This reverts commit 3476c1d60ec29c5497123194acd7a9310b1023d2.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two related issues.
1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to
communicate with its callback during each compartment switch.
This vector was designed to allow its contents to be stack-allocated
but they turned out to be accidentally heap-allocated.
2. During each tick, the stopwatch fills a vector `recentGroups_`.
This vector always started with minimal capacity and had to grow
repeatedly as groups were added, causing repeated reallocations.
This patch preallocates `recentGroups_` to have the same capacity as the
previous tick. We expect that this should eventually reach a stable size
that closely matches the actual needs of the process.
|
| |
|
| |
|
| |
|
|
|
|
| |
This enables optimizations which were wrongly inhibited before by this typo.
|
|
|
|
| |
Standards Compliance fix, port of Bug 1492737
|
| |
|
| |
|
| |
|
|
|
|
| |
This is a follow-up to ca7ecd37c94e268972697a37eec4e46771c6e6f2 further improving the DiD resolution for CVE-2018-12386.
|
|
|
|
| |
DiD fix.
|
|
|
|
|
|
| |
freshly initializes the TemporaryTypeSet* provided to it.
Also removes existing code that, quite unnecessarily, partly initialized that argument.
|
|
|
|
| |
Standard std::copy and std::copy_n are readily optimized to the same thing, and they don't have a non-obvious requirement that the type being copied be trivial.
|
|
|
|
|
|
| |
constructor, and copy-assignment operator.
This also allows uint8_clamped to be permissibly memmove'd and memcpy'd.
|
|
|
|
| |
VirtualRegister instances
|
|
|
|
| |
memset-on-nontrivial warnings with gcc that don't matter for an object whose lifetime is about to end
|
| |
|
| |
|
|\
| |
| | |
Fix more -Wclass-memaccess warnings (GCC8)
|
| | |
|
| |
| |
| |
| | |
as undefined the memory for the trailing array of BindingNames, ratther than impermissibly PodZero-ing non-trivial classes.
|
| |
| |
| |
| | |
of scope data into raw unsigned chars into which those BindingNames are placement-new'd, rather than memcpy-ing non-trivial classes around and failing to comply with the C++ object model
|
|\ \ |
|
| |/
| |
| |
| |
| | |
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
|
|/ |
|
|
|
|
|
|
| |
r=bbouvier, a=RyanVM"
This reverts commit 9472136272f01b858412f2d9d7854d2daa82496f.
|
| |
|
| |
|
|
|
|
|
|
| |
|entryCount| tracks -- in fast-to-check manner -- the number of entries in the hashtable. But to actually enumerate entries, we have to loop through all of |table|, checking for entries that are actually live. A live entry is indicated by a zero |hash| in the entry. The |memset| would properly zero that; removing the memset will not.
It's not entirely clear whether a memset that overwrites a lot of stuff but is maybe simpler, is faster than compiler-generated likely-SIMD code that zeroes out *just* |hash| fields in all the entries. But I am going to guess that SIMD is good enough. For now, we should just do the simple and thing: don't distinguish POD and non-POD, and know that the compiler is going to recognize that |mem.addr()->~T()| is a no-op when T is trivial. So with POD, the loop should degenerate to just zeroing |hash| at consistent offset, and SIMD will eat that up, and it can't be *that* different from the memset in performance (if it is at all).
|