RESOLVED FIXED 107651
Add an API for retrieving native memory information without going through the remote inspecting protocol
https://bugs.webkit.org/show_bug.cgi?id=107651
Summary Add an API for retrieving native memory information without going through the...
Marja Hölttä
Reported 2013-01-23 02:03:32 PST
We'd like to retrieve native memory information collected by the Developer tools via a WebKit API. The information we'd like to get is similar to what the native memory snapshot in Developer tools has (category name - amount of memory pairs). Possible use cases in Chrome: - memory tests - about:mem-internals page we're going to create ( crbug.com/168642 )
Attachments
Patch (14.60 KB, patch)
2013-01-23 05:59 PST, Marja Hölttä
no flags
Patch (15.20 KB, patch)
2013-01-23 08:22 PST, Marja Hölttä
no flags
Patch (18.41 KB, patch)
2013-01-25 01:51 PST, Marja Hölttä
no flags
Patch (15.93 KB, patch)
2013-01-25 05:04 PST, Marja Hölttä
no flags
Patch (18.44 KB, patch)
2013-01-25 05:04 PST, Marja Hölttä
no flags
Patch (6.91 KB, patch)
2013-01-25 07:31 PST, Marja Hölttä
no flags
Marja Hölttä
Comment 1 2013-01-23 05:59:31 PST
Yury Semikhatsky
Comment 2 2013-01-23 06:17:19 PST
Comment on attachment 184212 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184212&action=review Consider adding a sanity unit test for this under Source/WebKit/chromium/tests/ > Source/WebCore/inspector/InspectorMemoryAgent.h:66 > + void getProcessMemoryDistributionAsMap(const bool* reportGraph, RefPtr<InspectorObject>& graph, HashMap<String, size_t>* memoryInfo); You should change reportGraph to a bool, it is "const bool*" just to support optional parameters parsed by the generated protocol messages dispatcher. If you don't need to expose the graph to WebKit you could convert "RefPtr<InspectorObject>& graph" to "RefPtr<InspectorObject>* graph" and just pass 0. > Source/WebKit/chromium/public/WebView.h:381 > + virtual WebVector<std::pair<WebString, size_t> > getProcessMemoryDistribution() const = 0; WebView may not be the best place for this, it should probably go to WebDevToolsAgent
Marja Hölttä
Comment 3 2013-01-23 08:22:53 PST
WebKit Review Bot
Comment 4 2013-01-23 10:35:13 PST
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Marja Hölttä
Comment 5 2013-01-24 07:16:23 PST
abarth@, could you have a look at the API additions, if they're acceptable?
Adam Barth
Comment 6 2013-01-24 21:19:01 PST
Comment on attachment 184242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184242&action=review > Source/WebKit/chromium/public/WebDevToolsAgent.h:80 > + virtual WebVector<std::pair<WebString, size_t> > getProcessMemoryDistribution() const = 0; Does this std::pair represent some sort of object? Should we use a struct or a class in place of a std::pair? > Source/WebKit/chromium/public/WebDevToolsAgent.h:106 > + This change looks spurious. > Source/WebKit/chromium/src/WebDevToolsAgentImpl.cpp:645 > +WebVector<std::pair<WebString, size_t> > WebDevToolsAgentImpl::getProcessMemoryDistribution() const > +{ > + HashMap<String, size_t> memoryInfo = m_webViewImpl->page()->inspectorController()->getProcessMemoryDistribution(); > + WebVector<std::pair<WebString, size_t> > memoryInfoVector((size_t)memoryInfo.size()); > + size_t i = 0; > + for (HashMap<String, size_t>::const_iterator it = memoryInfo.begin(); it != memoryInfo.end(); ++it) > + memoryInfoVector[i++] = std::make_pair(it->key, it->value); > + return memoryInfoVector; > +} This looks really inefficient. Should we return an object that lets you query the map instead? I guess it depends on how you plan to use this data.
Marja Hölttä
Comment 7 2013-01-25 01:51:11 PST
Yury Semikhatsky
Comment 8 2013-01-25 03:47:00 PST
Comment on attachment 184701 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184701&action=review Can you do InspectorMemoryAgent refactorings in a separate change? > Source/WebCore/inspector/InspectorMemoryAgent.cpp:88 > + m_sizesMap = sizesMap; m_sizesMap should be a pointer or a reference, otherwise passed sizesMap will remain unchanged. > Source/WebKit/chromium/src/WebDevToolsAgentImpl.cpp:645 > + return memoryInfoVector; You can pass reference to WebVector<WebMemoryUsageInfo> as a parameter to avoid potential extra copies, the same for hash map returned by getProcessMemoryDistribution.
Marja Hölttä
Comment 9 2013-01-25 04:36:59 PST
Comment on attachment 184701 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184701&action=review >> Source/WebCore/inspector/InspectorMemoryAgent.cpp:88 >> + m_sizesMap = sizesMap; > > m_sizesMap should be a pointer or a reference, otherwise passed sizesMap will remain unchanged. Offline discussion: That's how it was before this patch, not going to change it. >> Source/WebKit/chromium/src/WebDevToolsAgentImpl.cpp:645 >> + return memoryInfoVector; > > You can pass reference to WebVector<WebMemoryUsageInfo> as a parameter to avoid potential extra copies, the same for hash map returned by getProcessMemoryDistribution. Offline discussion: not going to change this, other API funcs return WebVectors, too, let's be consistent...
Marja Hölttä
Comment 10 2013-01-25 04:37:18 PST
Comment on attachment 184242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184242&action=review >> Source/WebKit/chromium/public/WebDevToolsAgent.h:80 >> + virtual WebVector<std::pair<WebString, size_t> > getProcessMemoryDistribution() const = 0; > > Does this std::pair represent some sort of object? Should we use a struct or a class in place of a std::pair? I added a struct for this. >> Source/WebKit/chromium/public/WebDevToolsAgent.h:106 >> + > > This change looks spurious. Fixed >> Source/WebKit/chromium/src/WebDevToolsAgentImpl.cpp:645 >> +} > > This looks really inefficient. Should we return an object that lets you query the map instead? I guess it depends on how you plan to use this data. The keys are arbitrary (and can change as the dev tools add new metrics). So it wouldn't make sense to create a wrapper object with fixed accessors like CSSMemory(), PageMemory() and so on. Typical usage for this: E.g., in the memory tests, we'd loop through all the keys, and just input them to as data points to some entity which keeps track of memory metrics. Returning a std::map would also be okay, but it doesn't look like any of the API functions return maps.
Yury Semikhatsky
Comment 11 2013-01-25 04:40:46 PST
Comment on attachment 184701 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184701&action=review > Source/WebCore/inspector/InspectorController.cpp:438 > +HashMap<String, size_t> InspectorController::getProcessMemoryDistribution() const style: getProcessMemoryDistribution->processMemoryDistribution
Marja Hölttä
Comment 12 2013-01-25 05:04:05 PST
Marja Hölttä
Comment 13 2013-01-25 05:04:56 PST
Marja Hölttä
Comment 14 2013-01-25 07:31:06 PST
Marja Hölttä
Comment 15 2013-01-25 07:32:13 PST
I split out the dev tools refactoring parts, and committed them separately. abarth@: can you have a look at the new patch?
Adam Barth
Comment 16 2013-01-25 17:00:14 PST
Comment on attachment 184749 [details] Patch ok. Thanks for making an object instead of using a std::pair.
WebKit Review Bot
Comment 17 2013-01-28 00:55:18 PST
Comment on attachment 184749 [details] Patch Clearing flags on attachment: 184749 Committed r140951: <http://trac.webkit.org/changeset/140951>
WebKit Review Bot
Comment 18 2013-01-28 00:55:23 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.