When a thread is put to sleep another thread from an unrelated workload might then be selected to run in its place, replacing the data in the caches with new data. Putting a thread to sleep also has indirect performance effects.įor example, the caches associated with the core the thread was running on were likely holding useful data. Depending on the CPU and workload the thread state can range from several hundred bytes to a few kilobytes. In particular, putting a thread to sleep and then waking it up requires two context switches as well as saving and restoring the thread state to/from memory. However, putting a thread to sleep has significant performance implications and thus is not always the best option. This might seem counter-intuitive, as spinning consumes CPU cycles and power and is usually frowned upon in modern codebases. A thread attempting to lock an already locked instance of OSSpinLock will busy-poll the lock instead of waiting for it to be released, which is commonly referred to as spinning on the lock. On macOS we relied for a long time on OSSpinLock locks.Īs the name suggests these are not regular mutexes that put threads trying to acquire them to sleep if they’re already taken by another thread. ![]() To achieve this the allocator tends to use thin locks native to the underlying operating system. Specifically, creating mutexes and using them must not issue new memory allocations because that would lead to infinite recursion within the allocator itself. Locking within the allocator is implemented differently than in the rest of the codebase. ![]() To achieve this, jemalloc uses locks within its internal structures that are usually only held very briefly. Memory allocators have to be thread safe and – in order to be performant – need to be able to serve a large number of concurrent requests from different threads. We’ve diverged significantly from upstream jemalloc in order to guarantee optimal performance and memory usage on Firefox. This improvement was achieved via a small change in how locking is implemented within Firefox’s memory allocator.įirefox uses a highly customized version of the jemalloc memory allocator across all architectures. If you’re running Firefox on macOS you might have noticed that its responsiveness has improved significantly in version 103, especially if you’ve got a lot of tabs, or when your machine is busy running other applications at the same time.
0 Comments
Leave a Reply. |