Le 02/11/2013 20:41, Brendan Eich a écrit :
At JSConf.eu, John McCutchan of Google and a colleague who works on
gmail gave a good talk on GC, showing off Chrome's memory profiling tool.
Article version and longer talk at
http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/
They showed historical plots revealing gmail bugs, V8 GC regressions,
all the interesting dirt. Their tooling is great
I wouldn't say "great". It's state-of-the-art in web development, it's
the best things we have so far, but I still find the tool very hard to
use and I think I'm on the educated end of web developers when in comes
to memory management. Lots of Webkit/V8 internal machinery is exposed,
there is too much information and also too few of the needed information
(relationship to source code)... and... except for the high-level
indicator of memory, the information is displayed in tables and lists
which is at best ineffective for the amount of variety of information to
show.
It appears the tool was excellent for the Gmail team because they had
the V8 team around to collaborate with. Not the case of every webdevs.
In my opinion, Chrome tooling is way too low-level (and
engine-specific!), as suggested by the name ("heap snapshot") to be
useful to the average webdev.
Apparently IE11 comes with some memory-related tooling. I haven't been
able to put my hands on it yet, it'd be interesting to see how they
differ from V8 tool.
I think dcamp and team are on the case.
I think what's being worked on now is
https://bugzilla.mozilla.org/show_bug.cgi?id=923275 (high level memory
indicator).
I'm also experimenting on something (and been teasing Twitter about it
[1][2]). I'll post on the devtools mailing-list when I have something
presentable.
But when they called on JS developers to manage GC pause time, they
lost me.
How are JS developers supposed to manage pause time, even indirectly
(by avoiding unnecessary allocations and fixing leaks)? There's no
way. We won't be adding manually callable gc() built-ins to the standard.
They seem to take their experience with V8 as a generality. I think what
they meant was that allocating triggers GC which triggers copying
(compacting?), which costs, so be careful with allocations. But this
advice is hard to follow in practice.
This advice is also dependent on V8 allocation/GC scheduling strategy
and may be inappropriate in the future.
David
[1] https://twitter.com/DavidBruant/status/379033449438248960
[2] https://twitter.com/DavidBruant/status/379320523429117953
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
