| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
|\ |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
|\
| |
| | |
Simplify HeapSlot to make it trivially copyable
|
| |
| |
| |
| | |
This removes the constructors, which were never called since we allocate arrays of HeapSlot with pod_malloc. The destructor is only ever called explicitly since we free this memory with js_free so it has been renamed to destroy(). Also removed is an unused manual barrier.
|
| | |
|
|/
|
|
| |
Silences a warning with GCC 8.
|
|\
| |
| | |
Fix Build Bustage - with "--enable-debug"
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UXP uses the current stack frame address and the stack size
as a sort of heuristic for various things in the JavaScript
engine. The js::GetNativeStackBaseImpl() function is used to
get the base stack address (i.e. the address from which the stack
grows, so this can be either the first or last memory address of
the stack memory space depending on the CPU architecture).
On Linux, this function is implemented using the pthreads APIs.
For non-main threads, the queried thread info is stored in
memory. The main thread does not have this information on hand,
so it gets the stack memory range via the /proc/self/maps file
(see glibc's pthread_get_attr_np.c).
Fortunately (per discussions with the firefox devs in #jsapi)
the base address only needs to be approximate. In reality,
environment variables, args, and other things are stored in
stack space between the end/beginning of the mapped stack
memory and the 'top' of the stack space used by stack frames.
When using glibc, we can get the top of this usable stack from
__libc_stack_end, which is a void* set by glibc during program
initialization, avoiding the need to access /proc.
Non-main threads still get their stack-base through the usual
pthreads APIs.
Other libc implementations like musl will fall back to the
standard UNIX-like implementation which calls pthread's
pthread_attr_getstack() also from the main thread, which
may imply /proc access and not work in restricted
environments.
|
| |
|
|
|
|
| |
parallel tasks r=sfink a=abillings a=RyanVM
|
| |
|