1808440 - Make logalloc-replay handle threads.

Status: NEW

(Core :: Memory Allocator, task)

Description

[Paul Bone [:pbone]]

There's a few different ways to do this, with various levels of ease / accuracy.

Easiest / least accurate:
This is the minimum needed to work at all, we need to:

• In the logalloc-munge.py script Add just enough syncronisation points in a jemalloc-log so that allocations/frees of a particular address occur in the correct order when executed on multiple threads.
• In logalloc-replay replay the logs on multiple threads. Model the syncronisation points ad producer-and-consumer. Each synchronisation point is some kind of "already locked" lock, pthread_mutex will do. Produces unlock them and consumers lock them. They stay locked for the rest of the program. SysV semaphores might be better

above + Arena-aware:
In my opinion this is the minimum useful level. Only by using arenas will we measure allocator performance on multiple threads with arenas accurately.

• Add reporting for thread-local arenas https://bugzilla.mozilla.org/show_bug.cgi?id=1719790
• Add arena APIs to the logalloc-replay format. So that they can be replayed properly.

above + pthreads-aware:
Add pthread calls to the log and replay them to keep the replay threads more-or-less doing the same work in parallel with other threads, this would avoid some thread from racing ahead. IMO this would provide only an illusion of accuracy since other runtime conditions - not just the results of lock operations - will effect timing, and those won't be captured outside a much more managed language / instrumentation.