Closed Bug 1241352 Opened 4 years ago Closed 4 years ago
ICStub Space chunk size to reduce heap churn
I did some cumulative profiling with DMD and found that the chunk size of FallbackICStubSpace's allocator (256 bytes) is smaller than ideal, causing more calls to malloc/free than necessary. I tried changing it to 1024, 4096 and 8192, and found that 4096 was the best. Summary stats: - 256: Total: 4,227,855,576 bytes in 2,110,196 blocks - 1024: Total: 4,240,921,416 bytes in 2,071,114 blocks - 4096: Total: 4,184,653,168 bytes in 2,043,207 blocks - 8192: Total: 4,737,642,408 bytes in 2,096,809 blocks Choosing 4096 bytes minimizes the number of calls to malloc, reducing it by over 3% compared to 256 bytes. 4096 also reduces the cumulative size of those mallocs, which was an unexpected bonus; I think this must be due to reduced fragmentation. And it's also the same chunk size used by OptimizedICStubSpace. (Note: the 8192 numbers are a bit on the high side, possibly due to natural variation between runs. But when I dug into the numbers it was clear that 8192 was worse than 4096 because lots of the time these allocators allocate less than 4096 bytes.)
Comment on attachment 8710202 [details] [diff] [review] Increase FallbackICStubSpace chunk size to reduce heap churn Review of attachment 8710202 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Nicholas Nethercote [:njn] from comment #0) > And it's also the same chunk size used by OptimizedICStubSpace. Each BaselineScript has its own FallbackICStubSpace, but there's only one OptimizedICStubSpace per Zone. That's why FallbackICStubSpace's chunk size was so much smaller. You're the expert on this and if measurements show 4096 doesn't actually waste a lot more memory, it's fine to change it probably. Avoiding malloc is also nice for performance. Maybe we should have a single FallbackICStubSpace per Zone or compartment, but then we could only free its pages if the Zone/compartment has no Baseline scripts on the stack (Baseline scripts on the stack can't be discarded). Might be a reasonable trade-off..
Attachment #8710202 - Flags: review?(jdemooij) → review+
(In reply to Jan de Mooij [:jandem] from comment #2) > Maybe we should have a single FallbackICStubSpace per Zone or compartment, > but then we could only free its pages if the Zone/compartment has no > Baseline scripts on the stack (Baseline scripts on the stack can't be > discarded). Might be a reasonable trade-off.. Thinking about this more, worst case we could look at the scripts on the stack and mark any BumpChunks they're using, and free the other chunks. Let's land this patch first though. I'll do some measurements later and file a follow-up bug to see if we can move this allocator to the Zone.
I did some measurements in the browser and it's extremely uncommon (I got no hits at all) to have active Baseline scripts on the stack when we discard JIT code, so a per-Zone allocator makes sense. The only case I'm worried about is when scripts can run uninterrupted for a long time, for instance workers or the shell. In that case, a single Baseline script on the stack could prevent us from freeing any stub memory. Ideally we'd have something like a LifoAlloc with reference counted chunks. BaselineScripts could hold references to these chunks. Basically I want ExecutableAllocator but without the Executable part. I think it should be possible to move the pool related code out of ExecutableAllocator and into a new class, so we can reuse it here.
https://hg.mozilla.org/integration/mozilla-inbound/rev/406f2af156e70f008242c91eade94c50c7e8fdb3 Bug 1241352 - Increase FallbackICStubSpace chunk size to reduce heap churn. r=jandem.
You need to log in before you can comment on or make changes to this bug.