MemoryInfra: report base::SharedMemory in the heap profiler |
|||||||
Issue descriptionBackground context:go/memory-infra: memory profiling in chrome://tracing This came from the "15 MB reduction in Tumblur!" thread in project-trim@. Thinking about that, reporting the shared memory totals in general memory-infra counters is a bit tricky (bashi@ is looking into that in Issue 604726 ). But plumbing that to the heap profiler should be way easier and I don't see why that should escape the singularity :)
,
Aug 25 2016
,
Jan 4 2017
,
Jan 4 2017
,
Mar 3 2017
,
Mar 7 2017
Why do we need to hook this into heap profiler? We will have a dump provider and I assume that most of the shared memory is being reported by discardable and cc. Maybe we should add more dump providers instead of hooking into heap profiler.
,
May 23 2017
hajimehoshi@ is now working on how to report shared memory usage.
,
May 23 2017
I was wondering what is the difference from crbug/604726. Duplicated?
,
May 30 2017
Re #8: no. This is lower-prio specifically only about the heap profiler. Issue 604726 is about doing the right accounting at a MDP level, so we can use that for general memory-infra usage, UMA and whatnot (and is the more important big). This one, instead, is an add-on to add stacktraces to base::SharedMemory calls similarly to what we do for {malloc, blinkgc, partition_alloc}. That would allow us to see which code is causing shared_memory usage. Issue 604726 will just allow us to know the general total, and eventually the break down (eventually : if ownership edges are declared) by clients. This bug essentially involves plumbing a 4th AllocationRegister to base::SharedMemoryTracker and hooking insert/remove calls when --enable-heap-profiling is enabled. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ssamanoori@chromium.org
, Aug 5 2016