Open wesleywiser opened 5 years ago
The allocator doesn't need integration with arenas, but rather self-profiling can refer to either the allocator's (thread-local) counters or to arena counters (which would be even more accurate - basically you can subtract the space not actually used yet in arenas, which could be one counter in tcx, to make profiling faster).
cc @Zoxc @alexcrichton @SimonSapin (I believe there may be similar global allocators out there already, for tracking memory usage, what we need is something very lightweight and thread-local, so that we can accurately quantify how much space each individual query resulted in allocating)
cc @anp @Mark-Simulacrum
jemalloc already tracks quite a bit of information: http://jemalloc.net/jemalloc.3.html
Yeah, but we want a single per-thread counter, doing it on the Rust side would be cheaper (to read, especially if bare #[thread_local]
), and we can make it generic over any GlobalAllocator
so it still works even if we want to try out the system allocator.
We don't get to track LLVM allocations this way, but that can be seen as a good thing, since we are more likely to be interested in the rustc memory usage alone.
Idea from @eddyb:
It would be great if we could measure the memory used by the compiler during compilation in a very fine-grained way. One idea to do this would be to implement a custom allocator which could record statistics for memory allocated and deallocated. This allocator could also be integrated with rustc's arenas so that we could see exactly how much memory is used by each arena at any given instant.