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 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.
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.
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.
|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).
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.
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.
