I've done some investigation and prototyping and came up with a plan on https://bugs.chromium.org/p/v8/issues/detail?id=9186 .
Let me know if you have any thoughts! Thanks, Pierre Ulan Degenbaev writes: > Thanks, I see now that the new stats would also be useful for Chrome because > they are emitted after each GC whereas memory-infra gives heap stats > independent from GC. > > Adding "V8.GC_Heap_Stats" event to "v8.gc_stats" category and improving > 'tools/heap-stats' sounds good to me. > > On Tue, Apr 23, 2019 at 9:02 PM Pierre Langlois > <[email protected]<mailto:[email protected]>> wrote: > Thanks for the replies! > > Ah it's a shame we don't have a solution for d8. I've been toying with > memory-infra and it seems very useful, however, I was hoping for > something that would work regardless of the embedder, and that would be > friendly to building tools around it. > > At the moment for example, it's easy to write scripts that parse the > trace output from "v8.gc_stats". And for example, then we can use it to > track OPTMIZED_FUNCTION objects on the heap to see if a patch has > potentially improved code size. > > So I'm hoping to get heap statistics the same way, but I want to make > sure it's actually useful before sending out a patch :-). Already, if we > add an event for every GC it would show up in the chrome://tracing view > with heap details, so you could get a little more information in between > memory-infra dumps. Although a timeline with the heap going up and down > would be much better. > > On the V8 side of things, we could improve 'tools/heap-stats' to also > include heap statistics into the timeline, on top of object statistics. > > What do you think? > > Ulan Degenbaev writes: > >> I would also suggest to try memory-infra if you use Chrome. It can sample V8 >> heap stats periodically or on demand via the inspector protocol. It uses >> GetHeapStatistics() and GetHeapSpaceStatistics() API [1] >> >> I don't think we have a solution for d8. >> >> [1]: >> https://cs.chromium.org/chromium/src/gin/v8_isolate_memory_dump_provider.cc?rcl=c16fb58b2bca1bba7248ac509dde60ececf94d63&l=156 >> >> On Tue, Apr 23, 2019 at 12:46 PM Ross McIlroy >> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> wrote: >> +Ulan Degenbaev<mailto:[email protected]<mailto:[email protected]>> >> >> Hi Pierre, >> >> Have you tried the mem-infra >> category<https://chromium.googlesource.com/chromium/src.git/+/master/docs/memory-infra/> >> in chrome tracing? That should give you at least some of the items you are >> looking for if you select the "v8" item in a mem-infra trace event. >> >> Cheers, >> Ross >> >> >> On Thu, 18 Apr 2019 at 20:46, Pierre Langlois >> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> wrote: >> Hello! >> >> Lately I've been looking at V8's heap consumption and tooling around >> measuring and tracking it. I see we have a few different ways to do it >> and I've been thinking about adding a new one :-). So I thought I'd ask >> what you thought first. >> >> Essentially, I want to collect stats about the heap regularly, at >> every GC for instance, and then either plot this information over >> time, or do some statistics like getting the peak for each space, or >> figuring out how fragmented we are, ...etc >> >> So at the moment, to do things like that we can: >> >> * Use the V8 API or the inspector protocol. >> >> * Use --trace-gc-verbose to print statistics at every GC. >> >> * Use --trace-gc-object-stats or --enable-tracing with the >> "v8.gc_stats" category enabled to collect object statistics at every >> mark-compact GC. >> >> * ... something I missed? >> >> I started using --trace-gc-verbose and it works OK but its output is >> not very friendly for tools to consume. And on the other hand, I like >> how the TRACE macros work and are used with --trace-gc-object-stats. >> >> So I've been thinking about adding a new trace event that prints heap >> statistics, enabled with the existing `v8.gc_stats` tracing category. I >> haven't thought about all the details yet, but the current idea is the >> following: >> >> - Add a "instant" trace event for the "v8.gc_stats" category for >> every GC, both the scavenger and mark-compact, as opposed to >> --trace-gc-object-stats which triggers only using mark-compact. >> >> - The event could be called "V8.GC_Heap_Stats", to mirror >> "V8.GC_Object_Stats". >> >> - Output JSON with both global and per-space statstics, just like >> GetHeapStatistics() and GetHeapSpaceStatistics() from the V8 API do. >> >> How does this sound? Are there tools (tools/heap-stats?) that would >> benefit from this? Or do we already have ways to do this and I've missed >> it? >> >> Thanks, >> Pierre >> >> -- -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
