Hi Nicholas,
It seems that we have a similar goal :-) We have been prototyping yet
another memory profiler focusing on how objects are allocated:
https://wiki.mozilla.org/MemoryProfiler
(Well, the name is so general because I'm bad at naming. I'll rename it
if anyone feel that's improper.)
It is inspired by hprof and DMD and is designed to identify memory eager
codes directly. For example, it can show which (JS/C/C++) functions
retaining most:
SelfSize TotalSize Name
4653056 9502720 p/this.start
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
1310720 2097152 a
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
1245184 1245184 nsJSContext::GarbageCollectNow
1179648 1179648 PresShell::DoReflow
983040 983040 nsCycleCollector::collectSlice
983040 983040 IPDL::PHttpChannel::RecvOnTransportAndData
851968 851968 t/t.prototype._create
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:12)
or having highest peaks:
SelfHWM TotalHWM Name
6225920 17563648 p/this.start
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
6029312 6029312 s
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
4784128 4849664 nsDisplayBoxShadowOuter::Paint
1966080 1966080 IPDL::PHttpChannel::RecvOnTransportAndData
1769472 6684672 a
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
1572864 18153472 u
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
1572864 1572864 nsJSContext::GarbageCollectNow
1507328 1507328 PresShell::DoReflow
1507328 13500416 p/<.run/x/<
(https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
Other features include a timeline like that in Cleopatra so that
developers can zoom in and zoom out to focus on certain time intervals,
a tree view to show the call hierarchy and a filter to allow users to
concentrate on what interest them. We planed to annotate allocation
kinds (images, strings, js objects, etc) later.
The profiler is sampling based because the allocation events are
enormous. Both GC heaps, including nursery and tenured, and native heaps
are sampled. The sampler generates a lot of allocation and free events.
A few tables are kept and garbage collected so that free events can be
determined. Combining allocation with free events, the peak usage of all
functions/methods can be calculated, which is useful when looking into
the memory footprint of application start-up.
I discussed with :jimb and :fitzgen in the work week and they gave me
many great suggestions. Currently we are trying to retarget the profiler
to debugger APIs.
Hope this is useful and interest you.It would be great if we can share
the work and cooperate on it.
Best regards,
Ting-Yuan Huang
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
